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In July 1988, TAPR and AMSAT entered into the Joint DSP Program, 
in order to fund the development of an eventual DSP unit for Amateur 
usage. As of the 1993 Dayton HamVention, the direction of development 
was focused on a modular, standalone DSP system proposed by Bob 
Stricklin, NSBRG, in Dallas, Texas. The Stricklin KISS design, later 
renamed DSP-93, offers many of the things that the original project 
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specified. Fifteen months after the decision was made to proceed with 
DSP-93 development, TAPR and AMSAT are both proud to announce 
that orders for kits will be accepted from July 15th through August 31st, 
for the first 150 units. The DSP-93 will be supplied as a complete kit 
(including box and power supply). 


Look for TAPR at these Upcoming Events’ 


August 19-21 ARRL Digital Communications Conference 
August 26-28 | ARRL Southwestern Division Convention; San Diego 
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For those not wanting to build a 
kit, there are several preassembled 
DSP units on the market today. 
Ads for these units can be found in 
various publications. It is our hope 
that the TAPR/AMSAT joint 
DSP-93 project will expand the use 
of DSP in the Amateur community 
and become a tool for education. 


DSP-93 Design 

The DSP-93 is designed to 
provide radio Amateurs the 
wonderful capabilities of Digital 
Signal Processing in a stand-alone 
low-cost design. Not just limited to 
one mode, the DSP-93 can support 
data, audio, and video modes with 
the proper software. 


DSP-93 has been designed in a 
modular fashion with two 
four-layer boards using an 
interconnecting bus structure. The 
basic system includes a DSP 
engine board and a radio/computer 
interface board. The DSP Engine, 
bottom board, contains the 
TMS320C25 DSP, 32K by 16 bits 
of program and data memory 
(upgradable to 64K), the clock 
circuitry (40Mhz), and some 
programmable array logic for 
system I/O, The Radio/Computer 


Interface Board, top board, 
contains two eight-pin female 
mini-DIN connectors for radio 
interfacing. Incoming radio signals 
pass through a voltage divider to 
establish the initial levels, then 
through an_ eight-channel 
multiplex chip. The multiplex chip 
then feeds the single A/D input 
with either of the two radio inputs 
or one of the six auxiliary inputs. 
The Texas Instruments TLC32044 


Article submission deadlines for upcoming issues: 


Fall September 15 
Winter December 15 
Spring March 15 
Summer June 15 


The preferred format for submissions is plain ASCII text; but we can 
accept many popular word processor and graphic formats, If you have 
an idea for an article you would like to see, or you, or someone you 
know, is doing something of interest to digital communicators please 
contact the editor so that your work can be shared with the Amateur 


community. 


Packet Status Register (ISSN 1052-3626, USPS 005-419) is 
published quarterly by the Tucson Amateur Packet Radio 
Corporation, 1418 Ridgecrest, Denton, TX 76205. Membership in 
Tucson Amateur Packet Radio, including a subscription to Packet 
Status Register, is $15.00 per year in the U.S. and possessions, of 
which $12.00 is allocated to Packet Status Register. Membership is 
$18.00 in Canada and Mexico, and $25.00 elsewhere, payable in U.S. 
funds. Membership and Packet Status Register cannot be separated. 
Second-class postage paid at Denton, TX. 
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Analog I/O chip is used, which 
samples and updates at a rate of up 
to 45K operations per second and 
includes aliasing filters. This board 
also communicates to your 
computer at speeds up to 19.2K 
baud using a serial connection. 


The modular design of the 
DSP-93 allows for either of these 
boards to be replaced with future 
boards designed for any number of 
unique applications. It’s sort of like 
adding a new application card to a 
PC without redesigning the 
complete PC, The block diagram 
shows how the DSP-93 is 
interfaced, 


Basic Software Suite 

The initial offering of the 
DSP-93 will contain the following 
software: 


1200 baud AFSK, 300 baud 
AFSK, 1200 PSK, 9600 FSK 
terrestrial, 9600 FSK full-duplex 
for satellite operations, and various 
audio filters. These have been 
developed, tested, and have been in 
use during beta-testing. 


Software currently under test, 
which may or may not be released 
with the first batch of kits include: 
APT, Digital Oscilloscope, SSTV, 
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and HF modes. User interface 
software for DOS and Windows is 
also under development and 
testing. 


Future software will be 
distributed on the Internet, 
CompuServe, Amateur Satellites, 
and other systems, as well as being 
made available on disk as part of 
the TAPR software library. The 
idea of software for the DSP-93 is 


to make it as easy as possible to get 
and upgrade software in the future. 
Since the DSP-93 is an open 
architecture, it is hoped that as 
more Amateurs get their units, 
more software will be developed 
and distributed. 


Code Development 

A low cost shareware assembler 
is available for code development. 
To develop code for this board, you 
must have good reference material. 
You can find numerous books on 
DSP algorithms and developing 
DSP code. Manufacturers’ data 
sheets and books about the 
complex chips will also be good 
reference materials, All the details 
needed to write DSP code will be 
supplied with the kits. 


To make this project a bigger 
success, more people are needed 
who want to learn about 
developing DSP applications, 
networking, and converting from 
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the real linear world to the digital 
world. Ideally, everyone taking the 
challenge will select a particular 
idea and become so focused in the 
application that they become the 
expert. Some of the areas for 
development might include: new 
modulation techniques, speech 
synthesis, filters, spectrum 
analyzers, and many more 
applications you will think of. If 


you choose to work on the 
hardware aspects of this project, 
the modular approach should allow 
you to convert to other DSP chips 
or Analog I/O chips or to add 
additional capability. 


Future Options 
High Speed Radio Interface 

The High Speed Radio Interface 
board is a second radio interface 
board under development which 
has higher speed analog I/O chips. 
In general, its functionality is just 
like the Radio Interface Board, 
except that it contains the Burr 
Brown DSP101 Analog to Digital 
converter (used for input data) and 
the Burr Brown DSP201 Digital to 
Analog converter (used for 
output). The A/D chip is capable of 
200K samples per second with 
eighteen bits of resolution and the 
D/A chip can attain 300K updates 
per second with eighteen bits of 
accuracy. No date of release or cost 
has been set at this time. 
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Network Interface Board 

The Network Interface Board is 
intended to support higher speed 
modes which require moving large 
amounts of data to the computer 
faster than a serial port can handle. 
A National Semiconductor 
ST-NIC chip was selected for the 
task. The ST-NIC is working in the 
eight-bit mode. An 8K Static RAM 
buffer is included for network 


packets. The DSP-93 will be able 
to read and write to all the registers 
of the ST-NIC. This high speed 
data interface will be an advantage 


when dealing with video 
applications. The ability to utilize 
the card in a network environment 
will be limited and is intended to 
work only at a NETBIOS level 
with a very simple structured DSP 
protocol. The success of the 
network board will depend on the 
available DSP cycles left over 
between A/D samples after all 
other tasks are completed. No date 
of release or cost has been set at this 
time. 
TNC Interface Board 

The TNC Interface Board can be 
placed inside the DSP-93 for the 
decoding of HDLC frames for 


“packet cadio applications. The 


board provides the basic 
functionality required of a TNC as 
a low-cost option for those that 
require one entire unit, instead of 
hooking their DSP-93 to an 
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existing TNC at the station. No 
date of release or cost has been set 
at this time. 


Project Team 

Much of the development and 
current success of the DSP-93 
project can be attributed to the 
designers, developers, and testers. 


Designer: Bob Stricklin, NSBRG. 


Bob Stricklin, NSBRG and 
Greg Jones, WDSIVD. 


Joint DSP Project Officers: 
Robert Diersing, NSAHD 


(AMSAT) and Greg Jones, 
WDSIVD (TAPR). 


The Alpha-Team: 
Bob Stricklin, NSBRG, 


Frank Perkins, WBSIPM, 

Jon Bloom, KE3Z, 

Lon Cecil, WB5PKJ, 

Tom McDermott, NSEG, 
Robert Diersing, NSAHD, 
UoSAT/Doug Loughmiller, 
K0O5I/GOS YX, 

John Conner, WDOFHG, 

Greg Jones, WDSIVD, and 

Bill Reed, WDOETZ. 


The Beta-Team: 
Jack Davis, WA4EJR, 
Paul Beckmann, WAORSE, 
Scott Zehr, K9GKC, 
Ron Parsons, WSRKN, 
Jim Tittsler, 7J1 AJH/AI8A, 
Michael Zingman, N4IRR, 
Stan Salek, K.D6CVL, 
Mark Hammond, KC4EBR, 
Marcel Losekoot, 
Bill Beech, NJ7P, 
Gould Smith, WA4SXM, 
Roy Welch, WOSL, 
Greg Ratcliff, 
Brian Straup, NQ9Q, 
Doug Howard, KG5OA, and 
Robert Greenfield, VE3DSC. 


Any of the project members 
welcome questions about their 
work and involvement. If you 
know someone on this list, please 
ask them about their unit and how 
it operates. Personal contact with 
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testers is one of the best ways to 
determine the unit’s possible 
usefulness in your shack. Many of 
the testers are active on the 
satellites. 


Ordering your Kit 

The DSP-93 will sell for $430 as 
acomplete kit, including enclosure 
and power supply. 


TAPR kits can be complex 
depending on the kitting 
experience of each builder. We 
don’t think you will have trouble 
with the DSP-93 kit, but it does 
require some knowledge and 
experience to successfully go from 
a kit to a finished, usable unit, 
depending on the mode of 
operations. For data radio 
applications (i.e, 9600 baud FSK), 
special modifications must be 
made to your radio for proper 
operation of the DSP-93, Unlike 
other TAPR kits in the past, only 
the interface to the radio and the 
serial cable to the computer (DB-9) 
will be the responsibility of the kit 
builder. All other parts will be in 
the kit ready for complete 
assembly. 


Due to the cost of each unit, 
TAPR and AMSAT are unable to 
fund the total cost of inventory that 
may sit idle on the shelf for 
months. Neither organization can 
sustain such an investment at this 
time, with AMSAT Phase IIID 
developments and other such 
TAPR projects ongoing. To avoid 
this cost, TAPR and AMSAT are 
requiring that kit purchasers 
provide VISA/MC information or 
checks/money orders with their 
initial purchases. Money for the 
initial kit purchase will be 
deposited on September !5Sth, 
1994 to cover kitting costs, with 
kits being shipped beginning 
November 15th. If kits are 
available before November 15th, 
they will be shipped when 
available. Orders will be taken for 
the first 150 units. If more than 150 
units are ordered, then a second or 
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third batch will be done as soon as 
additional parts inventory can be 
purchased and kitted. In this way, 
the DSP-93 kit will be provided in 
the exact numbers required for the 
demand. Many of the parts in the 
DSP-93 have between 10-15+ 
weeks of lead time and have 
already been ordered for delivery 
by the end of September. After this 
initial kit offering, DSP-93 kits 
will be provided in batches as the 
demand warrants doing kits. The 
initial batch of kits will be as large 
as the demand requires, which we 
hope is large. The more the 
merrier! 


DSP-93 orders for the initial 
purchase will be taken from July 
15th through August 31st, 1994. 
Orders can be mailed to the TAPR 
address: 8987-309 E. Tanque 
Verde Rd #337, Tucson, Az, 
85749-9399, call (817) 383-0000 
(Office Hours: Tue-Fri, 
9am-12noon, 3pm-Spm Central 
Time), or fax (817) 566-2544. If 
you have questions concerning the 
unit, please write or call TAPR for 
an information pamphlet. The 
pamphlet will also be made 
available via fax through the 
TAPR voice system. 


Note to TAPR members: Since 
this is a joint project, this kit will 
not have a membership discount 
attached. 
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President’s Comer 


It’s been yet another busy 
quarter with projects, the FCC 
notices and rulings coming out, 
organizational issues, and lots of 
planning. I will hit briefly on some 
of the organizational issues and 
then cover the more troubling 
things — regulatory issues. The 
regulatory issues at work could 
eventually undermine how we 
enjoy our hobby. So, let’s start 
with the more pleasant things. 


DSP-93 

The DSP-93 project is about to 
wrap up and start into the 
production phase. As you can see 
from the announcement, kit sales 
are under way, For the price, this 
unit looks like it will do a lot of 
things and bring to a close over 
seven years of various work and 
effort by both AMSAT and TAPR. 
This project would not be finishing 
up if it were not for the great effort 
put forth by Bob Stricklin, 
NSBRG. Bob has committed 
uncounted hours to the project 
since early 1993. The beta-test 
group is off doing some hard work 
and it looks like they are working 
out all the kinks in what future 
builders will encounter. Without 
their efforts, the eventual kit would 
be much more difficult to construct 
and get operational. 


To avoid congestion at the 
TAPR office, the ordering will take 
place in batches, and we will take 
only as many orders for kits that 
have been allocated in the current 
batch. If you get in late in the order 
process, the worst that will happen 
is that your kit won’t be available 
until the next batch. Also — since 
the office has two phone lines, 
more people will be able to get in 
and leave orders on the voice 
system, without actually having to 
talk to someone about their order. 
Don’t forget, you can FAX your 
order in as well, I am looking 
forward to seeing great interest in 
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the DSP-93 and the start of an open 
architecture design that will allow 
the DSP-93 to meet untold 
Amateur needs in the future 
without having to wait months or 
years for DSP code development 
from within closed groups. I 
believe the wait has been worth it. 


AN-93 

In the May QEX, Johan Forrer, 
KC7WW, published an HF digital 
modem design. We approached 
Johan about doing his design as a 
kit, and since his design was 
turn-key and only needed to be 
kitted in a cost effective manner, 
the TAPR board decided to do 100 
kits to see if there was as much 
interest as we think there ts for this 
kit. We hope this becomes a long 
term kit for TAPR, since it opens 
up HF digital communications for 
considerably less than what a 
multi-mode controller costs. We 
will also be working with Johan in 
the future on some of his other 
digital projects. We hope Johan 
becomes an active designer within 
TAPR. 


SIGs 

The Special Interest Groups are 
having varying degrees of success. 
The NET-SIG is generating a lot of 
discussion, and with time, should 
produce some _ interesting 
monographs. Dave Wolf, Chair of 
the BBS-SIG, is looking for 
someone to take over the group. 
Dave is very busy with work and 
wants to find someone that will be 
able to devote more time than he 
can. | would think that from the 
3500+ BBS sysops in the US, a 
BBS-SIG will eventually be very 
active, Dave needs help right now 
from someone to oversee the 
Internet SIG mailing list and start 
working on discussion to get 
closure on various issues, Dave can 
be contacted through the TAPR 
office, if you don’t have his 
address or phone. The FCC 
Regulatory Committee has been 
busy working on several 
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regulatory issues, but there have 
been a few sidetracks the past 
month, with various folks’ work 
schedules and commitments 
having slowed things down. We 
are working on establishing an HF 
Digital SIG to discuss HF digital 
matters. More information on that 
as it develops. 


Advertising 

Just to prepare you ahead of 
time, the next issue of the PSR, 
Winter #56, will contain 
advertising. This is a result of a 
decision made at the 1994 TAPR 
Board of Directors meeting. With 
the help of Maingate Resources we 
are proceeding to implement the 
Board's decision. The main reason 
for implementing this is to make 
the PSR a self-supporting 
publication, and thus allow TAPR 
to utilize that portion of the 
members’ yearly dues in other 
areas. We hope that the various 
advertisers will bring needed 
products to the membership. If an 
advertiser is interested in 
advertising in the PSR, they should 
contact Maingate Resources, (817) 
295-6222. Also, if you use an 
advertiser seen in the PSR, be sure 
to mention that you saw their ad in 
PSR, Be sure to see this said again 
next issue (grin). 


Regulatory Issues 

Now to the more troubling 
trends in Amateur radio. There has 
been alot of FCC happenings since 
the last issue, Several are reprinted 
in this issue. These issues deal 
with: 

* Allocation of Spectrum Below 
S GHz transferred from 
Federal Government Use, 

« Authorization of Automatic 
Control for HF Digital Com- 
munications in Amateur Ser- 
vice Proposed, and 

« Commission Amends Rules 
Concerning Message For- 
warding Systems in the 
Amateur Service. 
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Each of these affects the future 
of how we operate Digital 
Communications, Let’s hit the 
most Important in terms of 
long-term impact. 


In February, the NTIA (National 
Telecommunications and 
Information Administration) 
posted a notice, entitled 
Preliminary Spectrum 
Reallocation Report, which was 
prepared pursuant to Title VI of the 
Omnibus Budget Reconciliation 
Act of 1993. In that Act, Congress 
mandated that the U.S. 
Government reallocate to the 
private sector 200 MHz of 
spectrum below 5 GHz, 100 MHz 
of it below 3 GHz. Since Amateur 
Radio’s use of the microwave 
bands is on a secondary basis to 
Government applications, mostly 
military, this proceeding will have 
a significant impact on our future 
access to these frequencies. From 
this, the FCC issued ET Docket 
No, 94-32, Allocation of Spectrum 
Below 5Ghz transferred from 
Federal Government Use. The 
spectrum identified for 
reallocation by the Department of 
Commerce is the 50 Megahertz at 
the bands 2390-2400 Mhz, 
2402-2417 MHz, and 4660-4685 
Mhz. Comment date was June 15th 
with reply comments by June 30th. 
We haven't seen all the comments 
and replies as of this writing. The 
goal of this ‘sale’ or 
‘redistribution’ of frequencies is to 
ensure spectrum for new services 
and the enhancement of existing 
services. Some independent 
analysis estimates that the FCC 
will raise several billion dollars in 
the sale of the first half of these 
frequencies now and probably 
double the amount when the rest of 
the frequencies are auctioned off in 
the upcoming years. This is the 
first of the great rush on 
frequencies which represent the 
future of many of our digital and 
other Amateur modes. 
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There is not much hope to save 
it, since we are now competing 
with companies and groups that 
have several million to drop on 
small portions of the bands being 
*redistributed,’ that we have taken 
for granted these last few decades, 
AMSAT has done well in getting 
the FCC to acknowledge the 
importance of satellite sub-bands, 
but we have a lot of work to do in 
order to try to ensure some future 
on these higher bands for any of 
our Amateur modes, The scenario 
which scares me is that we will be 
unable to be assigned as primary on 
any of the bands, so that within 
5-10 years the commercial 
operators in larger metropolitan 
areas will request that all Amateurs 
vacate those portions of the bands, 
since we will be secondary and 
thus interfering with their primary 
allocations, This would be the loss 
of almost all of our frequencies 
where some rather unique 
development is taking place. 


I believe that the only long-term 
plan that will save any of the higher 
bands being ‘redistributed’ is to 
ask the FCC for Amateur 
preserves. Think of them as 
national parks for public 
recreation. Not just for digital 
communications but for all modes. 
We don’t really need all of the 
frequencies that are being 
‘redistributed,’ but we sure need 
more than zero MHz. This is 
almost certain in the future if we 
continue as secondary allocations, 
We somehow have to be assigned 
small primary allocations on each 
of the bands, so that we can 
continue the development of 
technology that has already 
produced; MicroSats, packet radio, 
and much more. All of these 
advances in the radio art have been 
directly transferable to commercial 
technology and have generated 
many new markets. 


Many have said that Amateur 
radio should fold up and go home, 
since many of the things that make 
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Amateur radio unique can be 
attained by cellular, PCS, and other 
such technologies, Amateur radio 
is currently and has been in a 
paradigm shift for the last several 
years. We will either find a new 
definition of Amateur radio and a 
niche where it will continue to 
grow and prosper or it will 
eventually become something else 
— which is possibly not having 
Amateur radio at all. A good 
example of this was the recent 
agreement between McCaw 
Cellular Communications Inc., 
AT&T and the American National 
Red Cross. I am including the press 
release in this issue in case you 
have not read it, This is the future. 
More like this to come. Amateur 
radio will no longer be able to 
continue to provide services that 
are better offered by this type of 
technology. We can no longer try 
to validate our presence on 
frequencies based on methods of 
operations developed in the first 
half of the century, 


Before the 1950s, the Amateur 
community was made up mostly of 
experimenters. Since then the trend 
has been away from 
experimentation towards more 
operational type activities. Much 
of this has to do with the 
enhancement of technology and 
the opening of Amateur radio as a 
viable commercial market. As the 
Amateur radio market expanded, 
more folks needed to be reached, 
sO more and more *consumers’ 
were brought into the Amateur 
hobby. This continued the 
deterioration of the number of 
experimenters within the hobby. 
Now, will a manufacturer make a 
radio for these higher bands in 
order to grow a market for 
Amateurs when they can hold off 
on equipment development for 
several years and then sell the same 
equipment to commercial buyers 
for two or three times what 
Amateurs would pay — easy 
answer No,’ One possibility is that 
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we will lose our higher bands 
because Amateurs no longer 
experiment with technology in 
large enough groups to provide the 
critical mass necessary to create a 
market. The 2-meter band in the 
70’s and 80’s is a good example of 
this — Amateurs experimenting 
and making a market that is now 
significant. We have no 
burgeoning systems on 23cm or 
other like bands, since the 
technology is rather hard to deal 
with and very few are doing it. 
Why do something hard, when you 
can buy inexpensive equipment 
ready to go for 2-meter or 70cm? 
With few radios being available for 
these higher frequencies, no 
Amateurs are on them to make us 
viable to keep these now highly 
sought after and expensive 
resources. The future is indeed 
bleak. It might be UHF and above 
now, but the pressure will be on all 
of our frequencies eventually. We 
are using *BILLIONS’ of dollars 
of spectrum for recreation, and the 
warships are about to sail over the 
horizon and blow us from the 
water. 


TAPR will continue to work on 
the FCC frequency issue in 
conjunction with others in order to 
try to secure some amount of 
primary space we can call our own 
and not have to worry about 
investing in infrastructure only 
later to be asked to remove 
ourselves, because we are 
interfering with the primary 
occupant. 


Now the other two FCC issues. 
The HF proposal is good news. I 
will wait some more and see what 
kind of comments are made, but 
my hat is off to both the ARRL and 
ADRS for their effort in bringing 
this issue forward. The ruling is a 
mixture of the best of both worlds. 
I believe that the sub-band concept 
was proposed initially by Lyle 
Johnson, WA7GXD. In effect, the 
ruling states unlimited automatic 
operations can occur in one 
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sub-band on each HF band and 
unlimited semi-automatic 
operations on any portion of the 
HF bands that allows data 
transmission. Two potential 
problems could be that the defined 
narrow regions for fully automatic 
operations are possibly too narrow 
and the limitation of *500 Hz’ for 
semi-automatic operations reduces 
the possibility of future digital 
modes. The HF STA, which was 
initially for packet networking on 
HF, proved that the nature of 
automatic forwarding worked 
successfully, but if these regions 
are so limited as to cause so much 
congestion from several modes 
trying to utilize it, then no one will 
be able to communicate, Thus, 
everyone will operate 
semi-aulomatic. Maybe not a 
problem? Also, I can see why 
500Hz would be chosen, but that 
does indeed Jimit future modes that 
might operate at much higher 
speeds, but take up more than 
500Hz. If someone can operate at 
9600bps in 2Khz or 3Khz, 
wouldn't that be better than 
operating longer within 500Hz? 


The last issue deals with the 
ruling of Message Forwarding 
Systems in the Amateur Service. I 
believe that Phil’s petition for 
reconsideration covers al] the 
points I could make and had hoped 
TAPR’s Regulatory Committee 
would have filed within the 
deadline. Why is Amateur digital 
communications continuing to be 
held to higher standards than other 
Amateur modes? The originator of 
messages should be the only one 
held accountable for message 
content. That does not mean that 
with a BBS store-and-forward 
system, the first forwarding station 
operator should not review all 
incoming messages to help 
eliminate any problems, but the 
ruling is specific to one type of 
technology and does not address 
more advanced systems. Is this 
good or bad? Who can tell — 
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depends on further interpretations. 
A question I keep asking myself is 
why is Amateur radio, which is 
licensed, constantly being highly 


regulated, while Part 15 
operations, which are 
non-licensed, have few 


regulations? Somehow Amateur 
radio has gotten into this mode of 
having the FCC continuously 
regulate what we can do, instead of 
setting very broad definitions and 
allowing us to self-regulate 
ourselves. Self regulation is 
supposed to be one of our strong 
points - right? The ruling at least 
helps eliminate everyone in the 
current BBS forwarding system 
from getting fined, but still leaves 
one operator, spending lots of time 
and money to provide a resource to 
their local ham community to face 
legal action based on someone 
else’s illegal use. Why is this 
different from repeater networks or 
any other Amateur mode? These 
regulations are based on one or two 
occurrences over long periods of 
time, while the current digital 
store-and-forward network itself 
handles thousands of messages 
daily without problem or rules 
violations. Very troubling. 


If you have comments on these 
issues, please let me or the TAPR 
Regulatory Committee know. We 
need the membership’s input on 
these issues to ensure that TAPR is 
going down the correct paths. 


Till next quarter, and 150+ 
DSP-93 kits later. 


Greg Jones, WDSIVD 
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Introducing the AN-93 
TAPR Kit 


A low cost HF modem kit 
for RTTY, AMTOR, and 
Pactor applications. 


TAPR is proud to introduce a 
limited run (starting in September) 
of a kit designed by Johan Forrer, 
KC7WW. The AN-93 kit provides 
any PC user with the capability of 
operating RTTY, AMTOR, and 
Pactor with this simple 
modem-only design. AN-93 is the 
equivalent of a BayCom, BayPac, 
or PMP setup, but for HF digital 
operations. Johan developed this 
board in 1993 and published the 
design in the May 1994 QEX. 
Based on that article, we contacted 
Johan about doing his kit. This 
very simple kit is for the many that 
have wanted to play on HF, but 
didn’t want to pay the money for 
an expensive multi-mode 
controller. TAPR will be doing a 
limited run of 100 AN-93 kits. This 
is not a beta-test, but a market test 
to see what the level of interest is 
in this kit design. 


AN-93 Block Diagram 


With the AN-93, only three 
components are required for HF 
digital communications: a 
PC-compatible computer, the 
AN-93 modem, and software that 
performs the encoding and 
decoding. The AN-93 comes with 
a tuning indicator to allow visual 
tuning and the unit also provides 
audio output for an oscilloscope 
display. 


The TAPR AN-93 consists of 
one combined board, instead of 
two separate boards as shown in 
the QEX article. This was done to 
reduce the cost of board 
production. The combined board 
dimension is approximately 4" x 
3.5", so many common boxes will 
fit. TAPR still has a few Mouser 
40UB 102 boxes remaining; these 
were used for the PSK modem kits, 
but will hold the AN-93 kit as well. 


Half of the board is the 
demodulator and the other half is 
the tuning display and A/D 
convertor. Connections to the 
RS-232 serial and parallel ports are 
made through a 14-pin connector 
located on the display portion of 
the board. The AN-93 currently 


To Radio PTT “Sq pa 2 tl - 


To Radio FSK “Sy 


or 
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requires 9 volts @ 150mA, but the 
final kit may allow for 12 volts. 
Interfacing to the radio is through 
a DB-9; the RJ-11 receptacle was 
replaced to reduce kit cost. After 
the board is built, the filters must 
be aligned. TAPR is providing a 
simple method of generating these 
tones to allow simple tuning as part 
of the kit. The kit will be shipped 
with the A/D converter providing 
full-memory ARQ capability for 
Pactor. The TAPR version of the 
kit will provide both FSK and 
AFSK outputs for use with more 
common Amateur HF radios, 


Modem Specifications: 
* AGC at 100-mV audio input 
amplitude 
* Prefilter bandwidth 1 kHz 
* Discriminator channel filter 
bandwidth 120 Hz 
* 170-Hz channel separation 
* Data low-pass filter cutoff 200 
Hz 
* Automatic threshold corrector 
* Tuning indicator 
* A/D converter for “soft” error 
correction 
Shareware software is included 
along with Johan’s code. If you 
decide to use the shareware 
software, TAPR requests that you 
do submit the necessary 
registration fee to the author (not to 
TAPR). 


As of this printing, it has not 
been determined if the box can be 
included in the final price of the kit. 
The cost of the kit is currently 
estimated to cost $90. Kits should 
be available the first of September. 
If you are interested in getting an 
AN-93 kit when it is available, call 
the TAPR office to place your 
name and address on a mailing list 
so TAPR can contact you when the 
kits are ready to go on sale. 


For a full description of the 


AN-93 modem and _ its 
specifications, refer to the May 
1994 issue of OEX. 
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BBS-SIG 


Dave Wolf, WOS5H 


Packet: WO5H @ WOSH.#DFW.TX.USA. 


NOAM 
Internet: dwolf@tcet.unt.edu 


The next in-person session of 
the TAPR BBS-SIG will be at the 
upcoming ARRL DCC in 
Bloomington, Minnesota, August 
19-21. If you are a packet BBS 
sysop (any flavor of BBS, 
including the NOS variants), make 
plans to participate! 


Speaking of participation, the 
BBS-SIG is a great way to get more 
involved with TAPR and packet 
issues, if you’re so inclined, I 
suspect that the TAPR BBS-SIG 
has been sort of a well-kept secret, 
but this hasn’t been intentional. It 
is possible that relatively fewer 
BBS-types have access to the 
Internet than other packet hackers. 
If you DO have Internet access, 
when you receive a TAPR-BB, 
BBSSIG or NETSIG bulletin that 
lends itself to being ported to the 
Amateur packet network, please 
PORT IT! Be sure to include the 
unique BID (if you use the 
IMPORT function of your 
software, this will be automatic) to 
avoid the creation of a dupe. You 
don’t know how to usé the 
IMPORT function of your BBS 
software? Get on BBS-SIG and 
ask. That’s one of the reasons 
BBS-SIG is there! 


What’s been happening with the 
BBS-SIG lately? It’s been a quiet 
summer so far. The concept of 
creating a TAPR BBS Guide (that 
idea came from the Dayton 
BBS-SIG meeting) seems like a 
constructive way to jump start lots 
of struggling sysops. You don’t 
have to be a ’newbie’ to be 
struggling, either! The Guide 
would include recommended ’TO’ 
and ’@’ fields, too. If you would 
like to participate and can make the 
commitment to do so, please get in 
touch with me. 
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ARRL 13th Annual Digital 
Communications 
Conference 

August 19-21 


Do you operate a Digital mode 
(maybe Pactor, Packet, GTOR or 
AMTOR) now? Do you find it 
difficult to keep up with the latest 
digital technologies? Would you 
like to know more about digital 
modes? If you answered “yes” to 
any of these questions, then you 
should attend the 13th Annual 
ARRL Digital Communications 
Conference. Read on ... 


The Conference will be held on 
August 19-21, 1994 at the 
Thunderbird Convention Center, 
2201 East 78th Street in 
Bloomington, Minnesota. 
Accomodations are available at the 
adjacent Thunderbird Hotel, at the 
many Hotels and Motels located 
within a short distance, and also at 
several area RV\camper 
campgrounds. 


Enjoy a weekend of fun learning 
about the latest developments in 
TCP/IP, PACTOR, AMTOR, 
PACTOR-II, CLOVER, G-TOR, 
PACKET, DSP, and imaging. 
Participate in the nine forums 
about DSP, new HF modes, 
TCP/IP, VHF/UHF networking, 
BBS SYSOP issues and more. A 
glance at the program will show 
many forums that will catch your 
interest! 


One of the highlights of the 
conference will be the presentation 
of technical papers on the many 
aspects of digital communications 
throughout the day on Saturday. 
You will receive a copy of all 
papers presented. 


Many demonstrations of the 
latest in hardware and software 
will be presented. When you leave, 
you will have an in-depth 
understanding of the latest digital 
communications advancements 
and techniques. The Saturday 
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evening Technical Showcase will 
feature TAPR Special Interest 
Group meetings for BBS SYSOPs 
and on VHF/UHF network 
building and a technical paper 
presentation on “Low Cost HF 
DSP Modems” by Johan Forrer, 
KC7WW. 


The Hospitality Room will 
provide the place to meet old 
friends... and make new ones. At 
the Saturday luncheon you will get 
to know “who’s who” in digital 
communications. Meet the 
engineering staffs of 
manufacturers like Kantronics and 
Timewave Technologies. The 
optional Saturday evening dinner 
will provide another opportunity to 
make new friends. If you want a 
break from the Conference, the 
Mall of America, with hundreds of 
unique stores, is located within 
easy walking distance, Your 
family will enjoy Knott's Camp 
Snoopy theme park inside the 
Mall, The renowned Minnesota 
Zoo is only a short drive away, 


The Conference registration fee 
is $45 per person, which includes 
admission to all Conference 
activities, a luncheon buffet and a 
copy of the technical papers. An 
optional Saturday evening buffetis 
$20 per person additional. 
Registration deadline is August 
12th. 


For more information about the 
Conference or special Airline and 
Motel discounts call or write: 

ARRL DCC 
C/O Paul Ramey WGOG 
16266 Finland Avenue 
Rosemount, MN 55068 
Telephone: (612) 432-1640 

The host organization for the 
1994 ARRL Digital 
Communications Conference is 
the TwinsLAN Amateur Radio 
Club. 


See YOU at the Digital 
Communications Conference 
August 19-21! 
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Authorization Of 
Automatic Control For HF 
Digital Communications 
In Amateur Service 
Proposed 

(PR Docket 94-59) 


The Commission has proposed 
amending the amateur service 
rules to authorize automatic 
control of stations transmitting a 
digital emission on the High 
Frequency (HF) amateur service 
bands. 


This action was requested in 
petitions filed by The American 
Radio Relay League, Inc, (ARRL), 
and the American Digital Radio 
Society, Inc, (ADRS) 


The propagation characteristics 
of the HF bands allow for long 
distance communications. 
Amateur operators take advantage 
of these characteristics to 
communicate with other amateur 
stations all over the world, 
Establishing and maintaining a HF 
communications link, however, 
presents operating demands not 
encountered on the Very High 
Frequency (VHF) and higher 
frequency bands. The variables 
affecting communications in the 
HF bands are highly complex. To 
maintain the communications link 
and avoid causing interference to 
the communications of other 
amateur stations, the control 
operator constantly monitors the 
activity on the channel being used 
and adjusts the station’s 
transmitting parameters as needed. 
Because the presence of the control 
operator has been necessary for 
proper operation in these systems, 
automatic control of an amateur 
station that is transmitting on any 
HF band or on the 160 meter MF 
(medium frequency) band has not 
been authorized. 


In 1986 the Commission 
authorized automatic control of 
amatcur stations transmitting 


Page 10 


digital communications on the 
VHF and higher frequency bands 
and indicated it was interested in 
authorizing automatic control of 
stations using the HF bands. 


To determine solutions to the 
problem of avoiding interference 
from automatically controlled HF 
digital stations, the ARRL 
conducted a successful feasibility 
project under a special temporary 
authority the Commission granted 
to 50 amateur stations. The 
ARRL’s petition is based on the 
results of that study, The ADRS's 
petition contained an additional 
recommendation from amateur 
operators who have been 
experimenting for several decades 
with digital communications on 
the HF bands. 


The Commission said it was 
gratified by the cooperation and 
dedication of organizations within 
the amateur service community in 
determining the conditions 
necessary to allow automatic 
control of stations transmitting 
data and RTTY (narrow-band 
direct printing) emission types on 
the HF amateur service bands, It 
agreed with the petitioners that 
automatic contro] of amateur 
stations in the HF bands can, with 
safeguards, make the transmission 
of data and RTTY emission types 
practical and effective. 


Therefore, the Commission 
proposed to authorize automatic 
control for stations transmitting 
data and RTTY emission types on 
one specific subband of each HF 
band where such emissions are 
authorized, It also proposed to 
authorize communications 
between a locally or remotely 
controlled station and an 
automatically controlled station on 
any frequency where data and 
RTTY emission types are 
otherwise authorized. 


The Commission said that it 
firmly believes in the principle that 
government should be responsive 
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to user needs. It noted that the rules 
it proposed were the result of a 
successful feasibility project 
planned and carried out within the 
amateur service community and 
represent the recommendations of 
two organizations dedicated to 
bringing the benefits to be derived 
from the transmission of digital 
communications on the amateur 
service HF bands to amateur 
operators in the United States and 
elsewhere without causing 
unnecessary interference to other 
types of communications. 


Proposed Changes 

Part 97 of Chapter I of Title 47 
of the Code of Federal Regulations 
is proposed to be amended as 
follows: 


|. The authority citation for Part 
97 would continue to read as 
follows: 


Authority citation: 48 Stat. 
1066, 1082, as amended; 47 U.S.C. 
154, 303. Interpret or apply 48 Stat. 
1064-1068, 1081-1105, as 
amended; 47 U.S.C. 151-155, 
301-609, unless otherwise noted. 


2. Section 97,109 is amended by 
revising paragraphs (d) and (e) to 
read as follows: 


97.109 Station control. 


(d) When a station is being 
automatically controlled, the 
control operator need not be at the 
control point. Only stations 
specifically designated elsewhere 
in this Part may be automatically 
controlled. Automatic control 
must cease upon notification by an 
EIC that the station is transmitting 
improperly or causing harmful 
interference to other stations. 
Automatic control must not be 
resumed without prior approval of 
the EIC. 


(e) No station may be 
automatically controlled while 
transmitting third party 
communications, except a station 
transmitting a RTTY or data 
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emission, All messages that are 
retransmitted must originate at a 
station that is being locally or 
remotely controlled. 


3. Subpart C of Part 97 is 
amended by adding new Section 
97.221 to read as follows: 


97.221 Automatically 
controlled digital station. 


(a) This rule section does not 
apply to an auxiliary station, a 
beacon station, a repeater station, 
an earth station, a space station, or 
space telecommand station, 


(b) A station may be 
automatically controlled while 
transmitting RTTY or data 
emissions on the 6 m or shorter 
wavelength bands, and on the 


28.120-28.189 MHz, 
24.925-24.930 MHz, 
21.090-21.100 MHz, 
18.105-18.110 MHz, 
14.0950-14.0995 MHz, 
14.1005-14.112 MHz, 


10.140-10.150 MHz, 
7.100-7.105 MHz, or 
3.620-3.635 MHz segments. 


(c) A station may be 
automatically controlled while 
transmitting a RTTY or data 
emission on any other frequency 
authorized for such emission types 
provided that: 


(1) The station is responding to 
interrogation by a station under 
local or remote control: and 


(2) No transmission from the 
automatically controlled station 
occupies a bandwidth of more than 
500 Hz. 
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Commission Amends 
Rules Concerning 
Message Forwarding 
Systems In The Amateur 
Service 

(PR Docket 93-85) 


The FCC has relaxed the 
amateur service rules to enable 
contemporary message forwarding 
systems to operate at hundreds of 
characters per second while 
retaining safeguards to prevent 
misuse. 


A message forwarding system is 
a group of amateur stations 
participating in a voluntary, 
cooperative, interactive 
arrangement where 
communications from the control 
operator of an originating station 
are transmitted to one or more 
destination stations via forwarding 
stations, which may or may nol be 
automatically controlled, 


Currently, the control operator 
of each station is held individually 
accountable for each message 
retransmitted, resulting in 
unnecessary content review and 
delays. The American Relay 
League, Inc. (League) stated that 
the obligation of the control 
operator of the first forwarding 
station should be the establishment 
of the identity of the station 
originating the message. Only 
when this is not done should these 
control operators be held 
accountable for improper message 
content. Also, there are currently 
no central supervisory authority in 
an ad hoc amateur service digital 
network, making these 
unsupervised systems easy targets 
for misuse by uncooperative 
operators and non-licensees. 
Moreover, the Commission said 
that it could be difficult to establish 
after the fact that a particular VHF 
station originated a fleeting high 
speed digital transmission. For 
these reasons, the Commission 
said there must be on-going 
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oversight of the system and the 
control operators of the first 
forwarding stations are in the best 
position to provide such oversight. 


Therefore, the Commission will 
hold accountable only the 
licensees of the station originating 
a message and the license of the 
first station forwarding a message 
in a high speed message 
forwarding system. The licensee of 
the first forwarding station must 
either authenticate the identify of 
the station from which it accepts 
communications on behalf of the 
system, or accept accountability 
for the content of the message. 


The Commission also clarified 
that the station that receives a 
communication directly from the 
originating station and introduces 
it into the message forwarding 
system is the first forwarding 
station, 


" The League and the Colorado 
Council of Amateur Radio Clubs 
suggested that the Commission 


substitute the word 
“simultaneously” for 
“instantaneously” in the 


redefinition of a repeater. The 
Commission concurred and 
adopted this modification. 


The Commission believes that 
these rule changes will enable 
contemporary high speed message 
forwarding systems to operate as 
their designers intended, while 
retaining the minimum safeguards 
necessary to prevent misuse. 


Rule Changes 

Part 97 of Chapter | of Title 47 
of the Code of Federal Regulations 
is amended as follows: 


Part 97-Amateur Radio Service 


|. The authority citation 
follows: 


Authority: 48 Stat. 1066, 1082, 
as amended; 47 U.S.C. $$ 154, 
303. Interpret or apply 48 Stat. 
1064-1068, 1081-1105, as 
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amended; 47 U.S.C. 151-155, 
301-609, unless otherwise noted. 


2. Section 97.3 is amended by 
redesignating paragraphs (a)(28) 
through (a)(44) as paragraphs 
(a)(29) through (a)(45), 
respectively, adding a new 
paragraph (a)(28), and revising 
paragraph (a)(7) and redesignated 
paragraph (a)(36) to read as 
follows: 


97.3 Definitions. 


(a)(7) Auxiliary station. An 
amateur station, other than in a 
message forwarding system, that is 
transmitting communications 
point-to-point within a system of 
cooperating amateur stations. 


(a)(28) Message forwarding 
system. A group of amateur 
stations participating in a 
voluntary, cooperative, interactive 
arrangement where 
communications are sent from the 
control operator of an originating 
station to the control operator of 
one or more destination stations by 
one or more forwarding stations. 


(a)(36) Repeater. An amateur 
station that simultaneously 
retransmits the transmission of 
another amateur station on a 
different channel or channels. 


3. Section 97.109(e) is revised to 
read as follows: 


97.109 Station control. 


(e) No station may be 
automatically controlled while 
transmitting third party 
communications, except a station 
participating as a forwarding 
station in a message forwarding 
system. 


4. Section 97,205 is amended by 


adding new paragraph (g) to read 
as follows: 


97.205 Repeater station. 


(g) The control operator of a 
repeater that retransmits 
inadvertently communications that 
violate the rules in this Part is not 
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accountable for the violative 
communications. 


5. Section 97.216 is 
redesignated as Section 97.217, 


6. Section 97.219 is added to 
read as follows: 


97.219 Message forwarding 
system. 


(a) Any amateur station may 
participate in a message 
forwarding system, subject to the 
privileges of the class of operator 
license held. 


(b) For stations participating in 
a message forwarding system, the 
control operator of the station 
originating a message is primarily 
accountable for any violation of 
the rules in this Part contained in 
the message. 


(c) Except as noted in paragraph 
(d) of this section, for stations 
participating in a message 
forwarding system. the control 
operators of forwarding stations 
that retransmit inadvertently 
communications that violate the 
rules in this Part are not 
accountable for the violative 
communications. They are. 
however, responsible for 
discontinuing such 
communications once they 
become aware of their presence. 


(d) For stations participating in 
a message forwarding system, the 
control operator of the first 
forwarding station must: 


(1) Authenticate the identity of 
the station from which it accepts 
communications on behalf of the 
system; or 


(2) Accept accountability for 
any violation of the rules in this 
Part contained in messages it 
retransmits to the system. 
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Petition for 
Reconsideration of the 
Commission’s Rules 
Concerning Message 
Forwarding Systems in 
the Amateur Service 
(PR Docket 93-85) 


Phil Karn, KA9Q 


Petition For Reconsideration 

Although the Commission’s 
ruling is a welcome improvement 
over the previous state of affairs in 
which every station in a network of 
automatic message forwarders was 
held accountable for message 
content, it is nonetheless flawed 
and should be amended. 


In particular, the requirement 
that the “first forwarding station” 
either authenticate the identity of 
the originating station or take 
responsibility for message content 
is unworkable. The Commission 
has implicitly assumed a specific 
architecture for the message 
forwarding system that is rapidly 
being overtaken by new systems 
that render the concept of “first 
forwarding station” largely 
meaningless. 


The present message forwarding 
network consists predominantly of 
“packet bulletin board systems” 
accessed interactively by end users 
with relatively simple stations. 
Many of these user stations are 
either wholly non-computerized 
(e.g.,a “dumb terminal” connected 
directly to a Terminal Node 
Controller, or TNC) or use 
personal computers merely to 
emulate such a function. 


Although this may indeed be the 
prevalent practice today, the 
increasing availability of 
substantial computer power to end 
users is causing the amateur packet 
radio network to evolve rapidly 
toward more capability at the user 
Stations, with less in the network 
itself. This closely mirrors similar 
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trends in non-amateur computer 
networks, particularly the Internet. 


The Commission apparently did 
not consider these issues in its 
decision, hence the need for this 
petition for reconsideration. 


Two examples make this clear: 
the rise of “personal BBSes” and 
the amateur TCP/IP network (TCP 
and IP are the core protocols of the 
Internet). 


The personal BBS is just like a 
multi-user BBS, except that it is 
operated by and on behalf of only 
a single local user. In other words, 
the user and sysop are one and the 
same. Among the many 
advantages of the personal BBS is 
the immediate accessibility to the 
local user of messages previously 
received automatically by the 
BBS, as opposed to having to read 
them in real time across a slow and 
often congested packet channel. 


Such a personal BBS, however, 
looks like any other BBS to the rest 
of the network; the other nodes in 
the network will relay its traffic 
just as if it were a “regular” BBS. 
Yet the Commission’s ruling and 
its definition of “first forwarding 
station” appears to require every 
forwarding BBS in the network to 
treat such personal BBSes with 
special scrutiny that isn’t required 
for other BBSes that simply 
forward traffic from other users, 
Indeed, the new rule seems to 
require that messages from the 
sysop on even a multi-user BBS be 
treated differently from messages 
from other users on that system. 


Furthermore, consider the case 
where a personal BBS (or an end 
user with a “dumb terminal”, for 
that matter) connects to another 
BBS via a digipeater, a low-level 
device that simply relays physical 
packets. This digipeater would 
apparently become the “first 
forwarding system” and would 
therefore have to. take 
responsibility for the content of the 
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traffic it relays, even though it 
would not have to do so for traffic 
already relayed by another 
digipeater or BBS. 


This is clearly unworkable. 


The TCP/IP network shows 
even more clearly the trend toward 
removing higher-level functions 
from the network itself and 
pushing them toward the “edges” 
of the network, In a TCP/IP 
network, every user system 
provides functions analogous to 
the BBS, only much more 
sophisticated. Besides 
conventional BBS functions, these 
systems often provide file 
repositories and remote access to 
computing facilities such as UNIX 
systems. Many more sophisticated 
applications, borrowed from the 
Internet as a whole, are also 
appearing: graphical user 
interfaces, powerful resource 
search and query tools, and so on, 


However, the lower level 
functions in the TCP/IP protocol 
suite performed at intermediate 
systems are deliberately very 
simple; indeed, an IP router 
(packet switch) is conceptually 
similar to (and almost as simple as) 
the digipeater. It is important to 
understand that in a TCP/IP 
network, all of the nodes between 
two end user stalions {e.g., a user 
and a server node) are these 
low-level IP packet routers, and the 
end-to-end communications they 
support are real-time in nature. 
Furthermore, the protocols allow 
consecutive packets between the 
same end points to travel through 
different links and routers; the only 
reliable place to monitor the traffic 
between any pair of end points is at 
the end points themselves. 
Real-time auditing and approval of 
each packet is simply not practical. 


However, the wording of this 
present Order implies that the 
control operator of the first IP 
router forwarding traffic from an 
end user must either authenticate 
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that user or take responsibility for 
the end user’s traffic, even though 
the same router could confidently 
carry traffic that had already been 
forwarded by another router. This 
discrimination is wholly 
impractical and unacceptable; it 
may even be impossible. 


Ideally, the Commission ought 
to abandon all references to the 
“first forwarding station” and 
place all responsibility for message 
content on the originating station, 
which can be clearly defined as the 
station that first transmits the 
message on amateur channels. Any 
amateur station that relays or 
forwards traffic already 
transmitted and received on 
amateur frequencies, be it a 
repeater, digipeater, BBS, IP 
packet router or anything else, 
would not be held accountable for 
the content of the communication. 


As a possible alternative, | 
would be satisfied with a 
Commission interpretation of its 
ruling holding that the distinction 
between the “originating station” 
and “first forwarding station” 
applies only in the special case of 
a high level intermediate system 
such as a public BBS that speaks to 
“dumb terminals” on the user side 
and speaks BBS network protocols 
to the rest of the network. In the 
case of an end user system that 
speaks the network protocols 
directly (be they the BBS message 
forwarding protocols, TCP/IP or 
anything else) the originating 
station and the first forwarding 
station should be considered the 
same entity. Which in fact they are, 
since the originating station uses 
the same forwarding protocols as 
the rest of the network. 


{ am gratified that the 
Commission has seen fit to grant 
partial retief tothe niles that have 
so severely burdened the 
development of packet radio, 
However, I am concerned that the 
changes do not go nearly far 
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enough, and I urge _ the 
Commission to reconsider its 
decision, 


I understand that the 
Commission strongly prefers to 
establish principles of broad 
applicability that do not have to be 
constantly revisited as amateur 
technology and practice evolve. 
However, this ruling has clearly 
violated that principle by assuming 
a specific architecture for the 
amateur packet radio network that 
does not accommodate even near 
term future trends. I urge the 
Commission to rectify its oversight 
so that it does not have to revisit 
this issue again in the near future. 


Commercial 
Communication 
Companies Agree to 
Provide Emergency 
Communications for Red 
Cross 


[from a McCaw/AT&T/American 
Red Cross press release] 


An agreement has been signed 
by McCaw Cellular 
Communications Inc., AT&T and 
the American National Red Cross 
which formalizes a long-standing 
relationship between the 
organizations to bring important 
wireless communications and long 
distance services to disaster 
victims. 


The agreement was signed at the 
1994 American National Red 
Cross Convention in Seattle by 
McCaw Cellular Chairman and 
CEO Craig O, McCaw, AT&T 
Communications Services Group 
CEO Alex Mandl and Red Cross 
President Elizabeth Dole. It calls 
for McCaw and AT&T to rapidly 
provide free wireless and long 
distance service, cellular phones 
and volunteers to aid the efforts of 
the Red Cross’s emergency 
response team during times of 
disaster. 
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“This three-way partnership is a 
landmark event for us,” said Dole. 
“Giving our emergency response 
teams instant access to reliable 
wireless and long distance 
communication can make a 
material difference in our mission 
of providing relief and mitigating 
suffering." 


“McCaw Cellular and AT&T 
have been incredibly supportive of 
our efforts in the past.” Dole noted, 
“We have appreciated the 
relationship that has been 
established in so many of our 2,500 
chapters as well as during disasters 
where they have provided relief 
services and free calls for people in 
need. We salute their efforts in this 
stepped up commitment to serve.” 


Craig McCaw commented, “It’s 
no secret to relief agencies, public 
safety officials and our customers 
that our country’s wireless 
networks provide a reliable, 
durable and_ invaluable 
communications link during 
disasters. The lessons we have 
learned from working side by side 
with Red Cross personnel during 
the San Francisco and Los Angeles 
earthquakes, Hurricane Andrew 
and the Midwest flooding taughtus 
there is a role and, in our opinion, 
a responsibility to put our technical 
and human resources to work to 
help our neighbors during times of 
disaster.” 


“We are pleased that our phones 
and long-distance service will be 
supporting such a vital cause,” said 
AT&T’s Mandl. “The Red Cross 
helps so many people across the 
country, and assisting in its work is 
a great example of how anytime, 
anywhere communications can 
make the difference between life 
and death.” AT&T, which will 
provide 270 cellular phones and 
free long-distance service, has 
been a long-time supporter of the 
Red Cross. 


McCaw Cellular focuses a large 
portion of its community relations 
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work, corporate charity, public 
sector efforts and employee 
volunteer programs on emergency 
response activities. Days before 
the Los Angeles earthquake, for 
example, 150 senior managers at 
McCaw Cellular, including Craig 
McCaw and the company’s 
president Jim Barksdale, 
participated in a training exercise 
in which they received Red Cross 
disaster training and lived for two 
days as mock victims in a 
temporary shelter, The training 
was immediately put to use during 
the crisis. 


The agreement calls for AT&T 
cellular phones to be given to 
American Red Cross chapters 
across the country that are located 
in high-risk disaster areas. 
McCaw, which does business 
across the country primarily under 
the name Cellular One(R), will 
also use AT&T cellular phones in 
staging centers to be established in 
Pittsburgh and Denver. At the 
centers, a large number of phones 
and messaging devices will be kept 
“hot and ready” along with extra 
batteries and accessories to be 
dispatched to an affected area. 
Members of the American Red 
Cross Quick Response Team, who 
are the first people dispatched to 
disasters, will also be armed with 
the phones, 


McCaw/Cellular One and 
AT&T will make staff and 
resources available during 
disasters to establish mobile 
calling centers near Red Cross 
relief shelters to enable victims to 
call loved ones across town or 
across the world. 


McCaw Cellular 
Communications Inc, (Nasdaq: 
MCAWA) is the nation’s leading 
provider of personal 
communications services; a leader 
in the cellular industry’s transition 
to digital from analog service; and 
a leader in the introduction of 
wireless data transmission. The 
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company owns a 52-percent 
interest in LIN Broadcasting 
Corp., which is engaged in cellular 
telephone operations, television 
broadcasting and specialty 
publishing. McCaw Cellular is the 
nation’s fifth largest messaging 
service provider and also provides 
telephone service for commercial 
and private aircraft through its 
ownership of  Claircom 
Communications Group, L.P. In 
August 1993, McCaw announced 
it had reached a definitive 
agreement to merge with AT&T. 
Following regulatory approvals, 
the merger is expected to close by 
the third quarter of 1994. 


AT&T is the world’s 
networking leader, providing 
communications services and 
products, as well as network 
equipment and computer systems 
to businesses, consumers, 
telecommunications services 
providers and government 
agencies, 


The American Red Cross is a 
humanitarian organization, led by 
volunteers, that provides relief to 
victims of more than 60,000 
disasters a year and helps people 
prevent, prepare for and respond to 
emergencies. Founded in [881 by 
Clara Barton, the Red Cross is an 
independent, not-for-profit 
volunteer organization that relies 
primarily on the generosity of 
Americans for support. 


NOSintro Author, lan 
Wade Changes E-Mail 
Address 


If you bought a copy of 
NOSintro (TCP/IP over Packet 
Radio), and have tried 
unsuccessfully to contact me via 
the e-mail address listed opposite 
the Contents page, please note that 
I now have a new e-mail address: 
ian@netrider.demon.co.uk 


73 Ian, GBNRW 
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Non-Tech Topics 


Phase IIID - RUDAK-U 

As published in the last issue, 
Lyle Johnson, WA7GXD, and a 
highly competent group in support, 
are developing an_ entire 
user-oriented digital package for the 
Phase IIID launch called 
RUDAK-U. TAPR will be sending 
out a fundraising letter the end of 
July in order to raise the necessary 
$6,000 TAPR has committed to this 
project. The $6,000 represents 10% 
of the estimated cost ($60,000) of 
the RUDAK-U project. TAPR is 
doing a fundraiser in order to.collect 
the necessary money to help fund 
TAPR’s portion of the project. 
When the Board of Directors made 
the decision to fund this portion of 
the project, it was known that if 
TAPR did not receive the necessary 
membership support for $6000 in 
contributions, then this year's 
financial bottom line would be 
affected in a negative way. The 
RUDAK-U system has the 
capability of providing many of the 
features that we were all hoping to 
have some day on Phase IV. What 
Lyle has designed has some 
tremendous possibilities for 
providing both high-speed 
networking between regional 
groups and other more advanced 
activities. However, this project 
does require money, When you get 
the note from TAPR asking for a 
small contribution, please take a 
serious moment and help bring this 
unique project to the launch pad 
next year, If you have contact with 
a regional packet organization, 
contact them about contributing to 
an eventual satellite backbone 
system. This is not a kit or a 
publication, but your contribution 
to this project is making possible the 
creation of future infrastructure 
needed for the advancement of 
many of our current digital modes. 
Help fund a project that will lead to 
many new and exciting operational 
possibilities! 
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ARRL Digital 
Communications 
Conference 1995 

The American Radio Relay 
League (ARRL) has accepted 
TAPR’s request to co-host the 
1995 Digital Communications 
Conference (DCC). The 14th 
ARRL DCC will be co-hosted by 
TAPR and the Texas Packet Radio 
Society (TPRS) in the Dallas/Ft. 
Worth area during September of 
1995. TAPR would like to thank 
Tom Comstock, W5TC, and Mark 
Wilson at the ARRL for their 
support and help in getting the 
conference hosted in the West Gulf 
Division. 


TAPR in San Diego 

TAPR will be attending the 
ARRL Southwestern Divison 
Convention in San Diego, Calif., 
August 26-28. If you are a TAPR 
member and want to help out at the 
booth contact Greg Jones, 
WDSIYD, at (512) 794-0578. We 
look forward to seeing our various 
West Coast members. We will 
have kits and publications 
available as well as looking for lots 
of new members! 


TAPR to Distribute ARRL 
CNC and DCC Proceedings 

TAPR has made an agreement 
with the ARRL to be the 
distribution point for past 
proceedings of the ARRL 
Computer Networking Conference 
(CNC) and Digital 
Communications Conference 
(DCC) proceedings. This will 
apply to proceedings that are more 
than two years old. For example, 
the ARRL will continue to 
distribute the 12th (1993) and 13th 
(1994) proceedings this year, then 
next year, TAPR will distribute the 
12th (1993). 


In this way, TAPR and the 
ARRL hope that these proceedings 
will be made more accessible to 
interested hams. Proceedings 
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should be available from the TAPR 
office starting in the end of August. 


TAPR would like the thank 
Mark Wilson and Jon Bloom for 
their help with this arrangement. 


TUC-52/PCON Update 

The project spent the last quarter 
locating someone to do the board 
layout. Dave Dennis, NSBOC, in 
Dallas, has volunteered and has 
begun board layout, No other 
report at this time. 


Project Proposals 

The TAPR board has had 
several enquiries about project 
funding. All these requests have 
gone back to the requesters asking 
for a fully prepared proposal for 
consideration. If you have a project 
for the TAPR board to review for 
funding, request a proposal outline 
from the office or send Internet 
mail to tapr@tapr.org. 


Membership Growth 

The new and old members 
continue to pour in. Everyone at 
TAPR is very happy to see all the 
old members join back into TAPR 
and see where we are going in the 
future. The new member numbers 
also continue to increase. As was 
mentioned in the last issue, it is up 
to the local TAPR members to find 
and get other Amateurs in this 
mode to join and help support 
future projects and direction. As of 
the end of June, the TAPR 
membership roster has reached 
past the 50% point of our 2000 
member goal. Just another 
500-600 members are needed in 
order to reach this goal. Why 600? 
Well-TAPR will lose between 150 
and 200 members’ from 
non-renewals, so it always takes 
more new and renewing member to 
make up for those that decide not 
to renew. If you, or someone you 
know, is not renewing, please let us 
know why, so that we can better 
address your needs. 
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Packet TCP/IP Address Coordinators 
as of 15 June 1994 


The people listed here have volunteered to issue IP addresses for their 
areas. They are not paid to do this service; please understand that they are 
perfectly at ease to deal with coordination responses at a lower priority 
than the things that matter more, such as job and family. Please be patient 
when requesting an address. Please send corrections and updates to 
brian @ucsd.edu. 


44.002 Bob Meyer K6RTV 
44.004 DouglasThom N6OYU 
44,006 Don Jacob WB5EKU 
44.008 Brian Kantor WB6CYT 
44.010 Terry Neal AAGTN 
44.012 Steven King KD7RO 
44.014 John Shalamskas KJ9U 
44.016 Jeff Angus WA6FWI 
44.017 Dana Myers KK6JQ 
44.018 Geoffrey Joy KE6QH 
44,020 Fred Schneider KOYUM 
44,022 John Stannard KL7JL 
44.024 Dennis Goodwin KB7DZ 
44,026 RonHenderson WA7TAS 
44,028 Don Adkins KD5QN 
44.030 JGaryBender  WSS5N 
44.032 Bdale Garbee N3EUA 
44,034 Jeff Austen K9JA 
44.036 Doug Drye KD4NC 
44,038 Mike Abbott N4QXV 
44.040 Matt Simmons KG7MH 
44.042 John Martin KB5GGO 
44,044 Bob Wilson KAIXN 
44.046 Stan Wilson AKOB 
44.048 Jacques Kubley KA9FJS 
44.050 RonBreitwisch KCOOX 
44.052 Gary Grebus K8LT 
44.054 Ralph Stetson KD1R 
44.056 Johnathan Vail NIDXG 
44,058 Rich Clemens KB8A0B 
44.060 HowardLeadmon WB3FFV 
44.062 Jim DeArras WA4ONG 
44.062 Jon Gefaell KD4CQY 
44,064 Dave Trulli NN2Z 
44,065 BobApplegate  WA2ZZX 
44,066 John DeGood NU3E 
44.068.1-32 Bob Foxworth K2EUH 
44,068,.64+  BobBellini N2IGU 
44,069 Paul Gerwitz WA2WPI 
44.070 Gary Sanders N8EMR 
44,072 Ken Stritzel WASAEK 
44.073 Chuck Henderson WB9SUUS 
44.074 Mark Bitterlich WAS3JPY 
44.075 CharlesLayno §WB4WOR 
44.076 KurlFreiberger WBSBBW 
44.077 RodHuckabay  KASEJX 
44.078 Joe Buswell K5JB 
44.080 DougCrompton WA3DSP 
44.082 StevenElwood N7GXP 
44.084 Bob Ludtke KOMWM 
44.086 Reid Fletcher WB7CJO 
44.088 Bill Lyman NiNWP 
44.090 Mike Nickolaus | NFON 
44.092 Pat Davis KDSUU 
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Calif: Sacramento 

Calif: Silicon Valley - San Francisco 
Calif: Santa Barbara/Ventura 
Calif: San Diego 

Calif: Orange County 

Eastern Washington, |daho 
Hawaii & Pacific Islands 

Calif: Los Angeles - S F Valley 
Calif: Antelope Valley/Kern County 
Calif: San Bernardino & Riverside 
Colorado: Northeast 

Alaska 

Washington state: Wester (Puget Sound) 
Oregon 

Texas: North 

New Mexico 

Colorado: Southeast 
Tennesee 

Georgia 

South Carolina 

Utah 

Mississippi 

Massachusetts: westem 
Missouri 

Indiana 

lowa 

New Hampshire 

Vermont 

Eastern&Central Mass 

West Virginia 

Maryland 

Virginia 

Virginia (Charlottesville Area) 
New Jersey: northem 

New Jersey: southern 
Delaware 

New York: NYC & Long Island 
New York: ENY 

New York: WNY 

Ohio 

Chicago - North Ill, 
South/Central tit. 

North Carolina (east) 

North Carolina (west) 

Texas: south 

Texas: west 

Oklahoma 

Pennsyivania: eastem 
Montana 

Colorado: Western 

Wyoming 

Connecticut 

Nebraska 

Wisconsin, upper peninsula Michigan 
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44.094 Gary Sharp WDOHEB Minnesota 
— — Andy Warner NOREN (Minn-Twin Cities area only) 
44.096 Don Bennett K4NGC District of Columbia 
44.098 Brian A. Lantz KO4KS Florida 
44.100 Richard Elling KB4HB Alabama 
44.102 Jeff King WB8WKA Michigan (lower peninsula) 
44.104 CharlesGreene W1CG Rhode Island 
44.106 AllanBDayton NOKFO Kentucky 
44.108 James Dugal N5KNX Louisiana 
44.110 RichardDuncan WD5B Arkansas 
44.112 Bob Hoffman N3CVL Pennsylvania: westem 
44.114 StevenElwood N7GXP N&S& Dakota 
44.116 Tom Kloos WS7S Oregon: NW&Portland, Vancouver WA 
44.118 Carl Ingerson N1DXM Maine 
44.120 unassigned 
44.122 Dale Puckett KOHYD Kansas 
44.123 Bemie McDonnell NP2W Virgin Islands 
44.124 David Dodell WB7TPY Arizona 
44.125.0-126 Earl Petersen KF7TI Southern Nevada 
44,125.128-254 BillHealy © N8KHN Northern Nevada 
44.126 Karl Wagner KP4QG Puerto Rico 
44.128 Test Reserved for Testing 
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Everyone at TAPR hopes the 
membership is enjoying the new 
look and feel of the PSR, Bob 
Hansen, N2GDE, has been 
working very hard this year in 
transforming the look of the PSR. 
We hope that changes in the future 
will continue to help PSR and 
TAPR move into a new era of 
development and publications. 
Just as areminder, TAPR is always 
looking for articles every issue. 
PSR is a membership-oriented 
quarterly journal and depends on 
input from the entire body of those 
that participate in TAPR. In this 
way, more than just a handful can 
participate in what makes TAPR 
unique. Join the fun. 


International subnet coordinators by country 


44.129 Japan JGISLY Tak Kushida, 44.163.32 Costa Rica 
JH3XCU Joly Kanbayashi 44.163.48 Nicaragua 
44.130 Germany DL4TA Ralf D Kloth 44.163.64 Honduras 
44,131 United Kingdom GI1PLT Paul Taylor 44,163.80 El Salvador 
44.132 Indonesia YB1BG Robby Soebiakto 44.163.96  Guatamala 
44.133 Spain EA4DQX Jose Antonio Garcia. 44.163.112 Belize 
Madrid, (EA4DQX @ EA4DQX) 44.164,0-127 Surinam PZ2AC Otto Morroy 
44.134 Italy l2KFX 44.164.128-255 Trinidad&Tobago  9Y4UWI Dr. Patrick Hosein 
44.135 Canada VESJF Barry McLarnon 44.165 Poland SPS5SWCA Andrzej K. Brandt 
44.136 Australia VK2ZXQ John Tanner 44.166 Korea unknown 
44.137 Netherlands PAOGRI Gerard Van Der Grinten 44.167 India VU2LBW Lakshman (“Lucky”) Bijanki 
44,138 Israel 4X1GP Peleg Lapid 44.168 Taiwan BV5AF Bolon 
44.139 Finland OHiMQK Matti Aarnio 44.169 Nigeria 5NOOBA Kunle 
44.140 Sweden SMOIES Lennart 44.170 Croatia 7? Sinisa Novosel 
44.141 Norway LA4JL Per Eftang 44.171 Serbia (none) 
44.142 Switzerland HB9CAT Marco Zollinger 44.172 Srilanka 4S7EF Ekendra 
44.143 Austria OE1KDA Krzysztof Dabrowski 44.173 Mexico (pending) 
44.144 Belgium ON7LE 44.174 Brazil PP5AQ Luiz F. Catalan 
44.145 Denmark OZIEUI 44.175 Cuba CO2JA Jose Amador 
44.146 Phillipines DUiUJ Eddie Manolo 44.176 Turkey TA2LA Abdul-Hamid Sadka 
44.147 New Zealand ZL2BKC Wayne Knowles 44.177 Czech Republic OK2XTE Karel Odehnal 
44.148 Ecuador HC5K Ted 44.178 Russia RA3APW Karen Tadewosyan 
44.149 Hong Kong VS6YHJ Thomason FAN 44.179 Gibraltar ZBOD Jim Watt 
44.150 Slovenija S53FK Iztok Saje 44.180 Yugoslavia YT7MPB Miroslav Skoric 
44.151 France FC1BQP Pierre-Francois Monet 
44.152 Venezuela OA4KO/YVS Luis Suarez 44.193 OuterSpace-AMSAT WS3IWI_ Tom Clark 
44.153 Argentina LU7ABF Pedro Converso 
44.154 Greece SVIUY Demetre Valaris 
44.155 Ireland EI9GL Paul Healy 
44.156 Hungary HA8FN Laszlo Fidrich 
44.157 Chile CE6EZB Raul Burgos 
44.158 Portugal CTIDIA Artur Gomes 
44.159 Thailand HSiJC Kunchit Charmaraman 
44.160 South Africa ZS6BHD John 
44.161 Luxembourg LX1YZ Erny Tontlinger 
44.162 Cyprus 5B4TX C. Costis 
44.163.16 Panama 
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A Primer On Reliability As 
Applied To Amateur 
Radio Packet Networks. 


Tom C. McDermott, NSEG 
Texas Packet Radio Society, Inc. 


Scope 

Many messages [on NET-SIG] 
have been sent regarding the 
linking of a large number of packet 
radio switches, nodes, digipeaters, 
etc. Some authors have 
commented on the desirability of 
very long packet networks. This 
monograph will describe how to 
calculate the availability of such a 
system, given knowledge of the 
performance of the equipment 
used. 


Definitiions 
Let’s define some terms. There 
are 3 basic parameters that need to 
be known in order to make suitable 
calculations about network 
availability: 
MTBF = Mean Time Between 
Failures. This is the average 
(mean) time between failures of a 
particular piece of equipment. For 
example: an MTBF of 1680 hours 
would equate to a piece of equip- 
ment failing once every 10 weeks, 
on average. 


MTTR = Mean Time To Restore. 
This is the average (mean) time to 
restore a failed piece of equip- 
ment to service. For example: a 
piece of equipment with an MTTR 
of 8 hours implies that it takes 8 
hours to: 1) notice that there is a 
problem, 2) diagnose the prob- 
lem, 3) drive to the site, 4) repair 
the equipment, and 5) place it 
back in service. Of course the ac- 
tual series of event, and the time 
to restore all depend on whether 
the equipment is accessible at 
any time, backup equipment that 
may be available, etc. 


A= Availability. Thisistheportion 
of time that a piece of equipment 

(on average) is available for use. 
This can be calculated as follows: 
A=MTBF/(MTBF+MTTR) (1) 
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Series and Parallel 
Equipment 

There are two basic 
configurations of multiple pieces 
of equipment: 1) series, and 2) 
parallel. By this is meant the 
following: two pieces of 
equipment are in series if both are 
required to be operating correctly 
in order to get the job done. For 
example: suppose that you wanted 
to transmit a packet message across 
a 100-mile path, and there were 
two switches in the middle that 
were linked, and that the failure of 
either would prevent your packets 
from traversing the path. Then 
those switches, from a reliability 
point of view. are in series, The 
failure of either one of them would 
make the path not usable. In 
contrast, two pieces of equipment 
are in parallel] when either alone is 
capable of getting the job done, For 
example: suppose that you wished 
to send a packet between two 
points that were 50 miles apart, and 
you had a choice of either of two 
switches, each of which alone was 
capable of making the path, Then 
those switches, from a reliability 
point of view, are in parallel. 


Let’s use some of the basic rules 
of probability to derive the 
availability of networks of 
equipment that each have 
availability, A. 


Availability in series 

We can calculate the availability 
of n items, all with the same 
availability, A, that are in series, 
The combined availability is: 


An(ser) = A" (2) 


For example, suppose that we 
have a packet network consisting 
of 20 nodes, that each individual 
node has an MTBF of 4368 hours 
(6 months), and an MTTR of 168 
hours (1 week). Then the 
availability of a single node is 
4368 / (4368 + 168) = 0.963 
(96.3% of the time it works), The 
availability of a network of 20 of 
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these Hodes would be: 

0.963~~ = 0.470 

(47,0% of the time it works). We 
can see that, in general, putting 
items in series degrades the 
availability. 


Availability in parallel 

We can calculate the availability 
of n items, all with the same 
availability, A, that are in parallel. 
The combined availability is: 


An(par)=1-((1-A)") — (3) 


For example. suppose that we 
have a packet network consisting 
of 2 nodes, with MTBF = 4368 
hours, and MTTR = 168 hours, and 
these two are in parallel. Then the 
individual availability is 0.963 (as 
above) and the combined 
availability ig 

- (1-0.963)" = 0.9986 
(99.86% of the time it works). We 
can see that, in general, putting 
items in parallel improves the 
availability. 


More complex models 

Wecan calculate the availability 
of more complex networks by 
reducing them to series and parallel 
combinations that we now know 
how to handle. Sometimes, the 
combinations are not reducable to 
series-parallel combinations, but 
these cases are not common in 
Amateur packet networks. The 
general procedure is to break up a 
network into subsections that can 
be described as being in series or 
parallel. Then each subsection can 
in turn be broken up into smaller 
subsections that are in parallel 
and/or series, until the remaining 
network segments are entirely 
parallel or series. 


The availability of each 
subsection can be computed, and 
the subsection availabilities can be 
combined using (2) and (3) above 
to derive the network availability. 
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Some more examples 

Let’s look at a couple of 
example networks. Network one 
consists of 40 packet switches, all 
in series. It’s a long haul network, 
and skinny. Each node has an 
MTBF of 4368 hours, and the 
MTTR is 332 hours (2 weeks, since 
the sysop left on vacation 
yesterday, and does so frequently! 
- nice work if you can get it), Then: 


A = 4368 / (43684332) = 0.929 
An = 0.9297" = 0.053 


This network will function, 
end-to-end, 5 percent of the time, 
and will not work end-to-end 95 
percent of the time. Hmmmm. Ok, 
let’s assume that our sysop loses 
his cushy job, his extravagent 
vacation policy, etc., and can get to 
the site within 72 hours. Then the 
network availability would be: 


A = 4368 / (4368+72) = 0.984 
An=0.984"9 = 0.520 


Well, quite an improvement. 
The network actually works, 
end-to-end, 52% of the time. I 
guess we can all draw some 
conclusions about the level of 
service Our poor sysops are going 
to have to provide if we want this 
stuff to really work. Alternatively, 
we could do some work up front, 
and build dual redundant nodes. 
Those are ones with hot-standby 
eugipment that takes over the 
failed equipment with no loss of 
service (even after lightning hits!). 
Let's double the investment in our 
network by providing 
dual-redundant nodes at each of 
the 40 sites. Incidentally, building 
dual-redundant equipment without 
(joint) failures can be no small task 
in itself, The availability of this 
network, assuming our intrepid 
sysop finds out that he now takes 2 
week business trips all the time, 
can be calculated by breaking our 
network into some subsections, 
Each dual-redundant node is a 
subsection, and we have 40 of 
those subsections in series. So, first 
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we calculate the availability of the 
subsection: 


An(par) =( 1 -(1 -0.929)*) =0.995 


and then the availability of all sub- 
sections would be: 


Aao(ser) = 0.995°" = 0.817 


Well, that’s more like it. This 
network works 81.7 percent of the 
time, end-to-end, and the poor 
sysop can actually hold down areal 
job now. Ahhh, wait a minute. We 
have twice as much equipment in 
the network now, and thus it seems 
like twice as many things would 
break. Well, yes. Welcome to the 
dark side of the force — err, the 
dark side of high availability. In 
order to achieve this level of 
availability, we have to fix any 
failed equipment within 2 weeks 
— even if the failure does not take 
the node out of service. If we don’t 
fix it, then the remaining part that 
still works now determines the 
node’s availabilty, and we are no 
better off than before (at this node). 
So, there is no free lunch. Also, we 
have to be able to detect that 
something at the node has failed, 
even though it is still working. OK, 
so let’s just put up two different 
packet networks, each one of 
which reaches the two endpoints, 
but without any of this 
dual-redundant nonsense, In this 
case, we can model the two 
subsections as 40-element series 
connections of non-redundant 
nodes, and then we have two of 
these long strings in parallel. 


A4o(ser) = 0.053 (from above) 
A2(par)=(1-(1-0.053 )*)=0.103 


Well, this strategy didn’t work 
very well compared to making 
each node dual-redundant, did it? 
So it seems like our poor sysop is 
stuck in engineering 
dual-redundant nodes. 
Commercial telecom equipment is 
generally engineered this way. 
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What does it mean? 

So, one alternate seems to 
indicate a possible future for 
packet radio based on 
dual-redundant nodes, and 
overworked sysops; another 
scenario indicates that we cannot 
have all these nodes in series, i.e.: 
we need long-hop technology. 


TAPR Internet Update 


Due to the high amount of traffic 
to our Special Interest Groups and 
the TAPR Information List, TAPR 
wore out its welcome on the host in 
Tucson. We moved the three main 
lists from the tapr.org server onto a 
system at the University of North 
Texas. Thanks to Larry Lucas, 
NSXRZ, and the Texas Center for 
Educational Development at the 
University of North Texas, 
Denton, Texas for our access. 


To subscribe to these lists, 
simply send mail to 
‘listsery @tcet.unt.edu’; include in 
the message body the command: 
join groupname 

Example: 
join bbssig 

When you get tired of one of 
these groups, the command to 
remove yourself is: 
unjoin groupname 

Example: 
unjoin bbssig 

To get more information, send 
Internet mail to 
listserv @tcet.unt.edu’ and 
include in the body of the message 
the command ‘help’. The TAPR 
server has remained active and can 
be reached by sending mail to 
*file-request@tapr.org’. The 
electronic issue of the PSR is now 
being made available via the server 
as a file. If your club editor is 
looking for packet articles and 
information to republish, this is a 
great source. To get more 
information, send Internet mail to 
*file-request@tapr.org’ and 
include in the body of message, 
the command ‘help’. 
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ICOM’s IC-820H 
A Satellite User’s 
Perspective 


James Miller, G3RUH 
g3ruh@amsat.org 


These notes are herewith placed 
in the public domain. They 
represent the observations of the 
author, and are as accurate as I can 
possibly make them. They are not 
to be taken as either endorsement 
or damnation of the product in any 
way. I disclaim all responsibility 
for any Joss or damage, direct or 
indirect arising from use or abuse 
of this material. Caveat Emptor. 


Summary 
The ICOM IC-820H will, 
“straight out of the box:” 

* Work terrestrial UHF or VHF 
all-modes simplex/duplex 
very sweetly. 

* Work SSB/CW transponding 
satellites OK, albeit with a 
somewhat clumsy human in- 
terface. 

* Work satellite 1200 bps Pac- 
Sats OK, if you can accept 
doppler tracking with 100 Hz 
steps. 

+ Work terrestrial 9600 bps 
packet perfectly 


The ICOM IC-820H will NOT: 

* Work 9600 bps satellites “outa 
the box;” A modification is 
needed. , 

The ICOM IC-820H has a 
number of positive features; 
beautiful construction, small size, 
excellent documentation, good 
frequency management. 


The ICOM IC-820H has a 
number of negative features 
having to do with pre-amplifier 
and linear amplifier control, power 
output control, internal switches, 
and coarse doppler tracking. 
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Introduction 

A while ago (June 1994) 
Icom-UK kindly loaned me an 
Icom-820H transceiver to 
evaluate. Like you, loads of 
questions came to mind. I wanted 
to know: “What’s the Icom-820H 
like? Is it really a 9600 baud packet 
radio which is data ready right out 
of the box? What about 1200 bps 
PacSat use? Would PSK be 
decodeable? Would the VFOs 
track sensibly? Doppler tuning 
facilities? Satellite ready?.” And 
many more. 


This is not a full-blooded OST 
review plastered with microvolts 
and decibels. That’ll come from 
the ARRL Lab. But I have 
measured what I needed to know. I 
also assume the reader knows how 
to use a Satellite, has a reasonable 
idea of what to expect from this 
sort of radio, and doesn’t (say) 
need “reverse tracking” explained. 


I’m recording the interesting 
differences between established 
practice as popularized by the 
Yaesu FT-736R, and typical user 
expectation — mine. 


First Impressions 

The manual is a model of clarity. 
Outstanding. Yaesu please copy. 
The schematics are not quite up to 
Kenwood standard; need more 
annotation, frequencies, signal 
names and highlighted principal 
paths. This would help 
understanding a lot. 


Anyway, I located the 
discriminator and varactor stuff 
OK, various internal switches etc, 
and things looked promising. 


Then I connected up two 
dummy loads, switched on the 
radio, and played with all the knobs 
and buttons until I’d hacked the lot. 


The Product 

The IC-820H is a dual-band 
144/430 MHz full-duplex 
all-mode transceiver, It has 100 
tunable memories, 10 tunable 
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satellite memory pairs and six 
assorted others. Output is 30-45 
watts. Mine also had an extended 
receive range: 136 to 174 MHz 
which was very useful. This 
feature is not documented in the 
manual. 


The radio is small. It’s 2/3rds the 
height, width and depth of a Yaesu 
FT-736R. But then it has no 
internal mains power supply, and 
neither will it accommodate two 
extra band modules like the Yaesu. 
Itrequires a 13.8 volt supply, about 
16 amps, and is suitable for mobile 
operation. A microphone is not 
supplied and neither is a carrying 
handle. 


In England, the combined cost 
of the radio and a PS-55 supply 
(GBP 245) is about GBP 1940; an 
FT-736R from the same dealer is 
GBP 1700, GBP = Great British 
pounds sterling. 


The Hidden Features 

Being small there are only 32 
buttons and knobs on the front 
panel compared with 67 on the 
Yaesu, so the lesser used functions, 
about 20 of them, such as dial dim, 
pre-amp feed control, RIT rate, 
CAT baud rate and so on are 
pre-stored via a configuration 
process. To invoke this requires the 
radio to be switched off and on 
again up to four times, which 
seemed unnecessarily clumsy to 
me, Some other functions are 
relegated to slide switches inside 
the radio, and adjustment requires 
you to remove the covers. This 
takes a few minutes. See you later. 


Normal Tuning Management 

The radio is organized around a 
Main Band and a Sub Band, each 
assigned to UHF or VHF or vice 
versa. You transmit on the Main 
band only. You receive on both 
Main and Sub simultaneously. 
There are duplicated volume and 
squelch controls; Main appears in 
the left headphone, Sub in the 
right; an internal switch allows 
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these sounds to be mixed or 
separated. There is an internal 
speaker and there are two external 
loudspeaker sockets; smart wiring 
selects the expected sum/separated 
combinations, 


Storing, retrieving, and 
swapping frequencies and modes 
is a doddle. Everything you could 
possibly expect is provided. 
Tuning rates are very sensible, and 
can be quickly adjusted from | 
MHz right down to | Hz resolution 
on SSB/CW, 100 Hz on FM. There 
are two VFOs each, for VHF and 
UHF, plus 100 tunable memories 
initially apportioned 50/50 
between VHF and UHF, but you 
can alter this up to 80/20 either 
way. 


The idiom is a little different 
from the FT-736R’s, and took 
practice to acquire, but within a 
couple of hours it became second 
nature. I liked having both 
frequencies in view. The amber 
LCD display has very crisp 
characters and delights the eye, 


Because you transmit on Main 
and receive on Sub, and can control 
each quite independently, you can 
(and do) operate satellites when in 
“normal” mode. 


Unfortunately RIT, passband 
Shift and optional CW-Narrow do 
not work on the Sub band, i.e. on 
the full-duplex receive frequency. 
Neither do manual AGC fast/slow 
select nor the mechanical S-meter. 
Instead, on the Sub band CW or 
SSB mode automatically chooses 
AGC fast or slow for you, and 
there’s an LCD bargraph S-meter. 


Satellite Tuning 
Management 

When you enter “Satellite” 
mode either the satellite VFO pair 
is used, or one of the 10 satellite 
memory pairs, or you can transfer 
the “Normal” frequency pair 
across (and back again when you 
leave). 
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When in satellite mode, Main 
and Sub band frequencies track 
together, either normal or reverse 
— as for example with Oscar-13 
mode-B. 


Alas, there is no proper 
“untrack” facility; to alter one 
frequency independently of the 
other you have to hold in one of 
two alternative front panel buttons 
whilst turning the main tuning 
knob. With practice I managed 
sort-of using my thumb and 
forefinger for the main knob, and 
third or fourth finger for the 
buttons; left handers would find it 
nearly impossible. It’s really a two 
handed job, and is excruciatingly 
fiddly, 


I discovered an undocumented 
kludge that partially obviated this; 
using the microphone Up/Down 
buttons, only one frequency 
changed, However the smallest 
step size from the mic buttons is 
100 Hz, (See later), 


In fact, to tune TX and RX 
independently you need to adopt a 
change of attitude to the radio, Just 
forget all about a so-called 
“satellite” mode! 


Do your satellite operating in 
“normal,” and only engage 
“satellite” when you want to do a 
quick bit of ganged tracking, or 
retrieve a frequency pair from the 
10 satellite memories. I don’t think 
this is how the designers envisaged 
things. 


Intriguingly, there is a blank 
button position actually marked 
Satellite, sandwiched between 
Normal and Reverse. I wonder 
why it’s not fitted and called 
“Untrack”? Perhaps once it was. 


As before, since satellite mode 
receive is on Sub band, passband 
Shift, CW-Narrow, manual AGC 
fast/slow select and mechanical 
S-meter are inoperable, but a RIT 
has been provided. (Does anyone 
ever use RIT?) 
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It would have been far, far better 
if there were a genuine “satellite” 
mode with Main receive and Sub 
for transmit. Main has the larger 
digits which are square in the 
middle of the radio and it’s clearly 
the object of your visual, mental, 
and operating focus. And of course 
Main has all the RIT/SHIFT 
/CW-N/AGC/METER controls 
working for it. 


really wish I didn’t have to say 
this, but “satellite” mode looks at 
best to be an afterthought grafted 
on because the control 
microprocessor makes it easy. “It’s 
only software.” 


The Yaesu FT-726R first 
appeared ten years ago, the 
FT-736R six years, so the 
operational needs of satellite 
operators are well established. 
Why has Icom made such heavy 
weather of it? 


Preamplifiers & Linear Amps 

You can send +l0v up either, 
both, or neither of the VHF/UHF 
antenna sockets. This supply is 
removed from the relevant socket 
on transmit. 


The manual does not specify a 
maximum loading; I tried 100 ma 
and 200 ma and the voltage 
remained steady; at 330 ma it 
began to droop. The limit is set by 
dissipation in a PQ20VZ51 
regulator on the display unit. 


Other than this 10v supply, there 
is no provision for hard switching 
of pre-amplifiers or linear 
amplifiers unless you confine 
yourself to one band, when youcan 
of course use the PTT line via the 
accessory socket. Serious 
operators will regret this omission. 
Incontrast, the Yaesu FT-736R has 
four control lines, one for each 
band. 


Internal TX/RX changeover is 
by PIN diodes, so it’s fast and 
silent. 
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RF Power Control 

The front panel sports a 
high/low power control button, 
Low power is 4-5 watts, 


If you have an external linear 
amplifier or a transverter you need 
to be able to vary the output power 
continuously. There is no knob 
provided for this. 


There is instead an ALC facility 
on the accessory socket. The 
control voltage is -4 to 0 volts into 
“more than 10K,” but you must 
provide a supply and a pot to do 
this. And a box, and a place to put 
it. Tacky. There’s some free space 
on the rear pane! though. 


There are several ways to key 
this transmitter; there’s the Tone 
button, mixed in with other 
frequently used buttons and easily 
hit. Then there’s the bigger 
Transmit button, and the normal 
PTT (mic or TNC). More than once 
I accidentally hit the Tone button, 
sending a minimum of 4 watts 
skywards,. That would have wiped 
out my S-band converter had it 
been connected. 


RF Attenuators 

You can attenuate the RF input 
of either or both receivers, by | 5db, 
from a front panel button. This is 
in lieu of a (big) RF Gain knob, and 
is an excellent feature. Many 
preamplifiers have far too much 
gain; an S-band pre-amp plus 
converter most certainly does. 
Being able to cut the signal down 
to size prevents cross modulation 
and overloading. 


Digital Satellite/Terrestrial 
Operation 

Before describing this, it’s 
necessary to tell you how the data 
input and output audio is routed, 
because it is not unconditional. 
You might like to draw yourself a 
little sketch. 


Both signals are presented to the 
8-pin DIN Accessory socket on the 
rear panel. 
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The incoming transmit audio 
(TXAudio) passes though a slider 
switch marked PACT/AMOD: 

* In the AMOD position the 
TXAudio passes to the Main 
subsystem where it meets up 
with the regular pre-amplified 
microphone sound for use in 
FM or SSB modes, and then 
through some audio process- 
ing. 

* Inthe PACT position the audio 
goes directly to the varactor 
diode of Main’s FM section. 

The receive audio (RXAudio) 
also. passes through the 
PACT/AMOD slider switch: 

* In the AMOD position, 
RXAudio is picked up from 
either the Main or Sub 
receiver, according to the set- 
ting of another internal slider 
switch marked MAAF/SAAF, 
and is squelched. 

* Inthe PACT position the audio 
is collected directly from the 
discriminator of the Main FM 
circuit, via a 4.7K resistor and 
100nF coupling capacitor, It’s 
unsquelched of course. 

These switches are not 
accessible without removing the 
bottom cover. An access hole 
could surely have been placed next 
to the accessory socket, which 
would allow these switches to be 
tickled with a small screwdriver. 
Users will probably drill a couple 
of holes in the bottom, or cut away 
some of the underside ventilation 
grill. 


But why should you need to 
touch them at all? Read on. 


1200 bps PSK Satellites 

FO-20, PacSat, Lusat, and 
Weber require an FM uplink, to 
which is applied audio PSK. The 
downlink is conventional carrier 
PSK, and the system is full duplex. 
Therefore the internal switches 
must be set to AMOD and SAAF 
(see above). 
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The uplink “eye” as received at 
the satellite is OK; it’s pinched 
about 4 db, Remember the 
TXAudio has been through the 
regular FM modulator circuits. It’s 
a good idea not to yell into the 
microphone ut this time, unless the 
Mic gain pot is at minimum, since 
both signals are added. If you flip 
the MOD switch to PACT the 
uplink modulation is text-book 
perfect, but then you lose your Sub 
band PSK receive audio! You get 
Main FM. Grrr! 


Downlink 1200 bps PSK 
reception from the Sub band 
receiver is excellent, as too is 
Oscar-13’s 400 bps telemetry 
Signal, 


The only snag with these 
PacSats is doppler tracking the 
PSK signal. (See later). 


9600 bps DFM Satellites 

Uosat-22, KitSat-23, etc. 
require the TXAudio to be applied 
direct to the transmit FM varactor. 
RXAudio must be picked off 
directly from the FM 
discriminator, and the system is 
full duplex. 


Thus the internal MOD slider 
switch needs to be set to PACT. 
But that immediately picks up the 
wrong RX audio — from FM 
Main’s discriminator. For satellites 
we need FM Sub’s discriminator 
output. 


Consequently you CANNOT 
operate the 9600 bps satellites with 
an Icom IC-820H “straight out of 
the box.” 


There is a solution, but we’re 
back to modifications I’m afraid. 


What you do is locate the Sub 
receiver discriminator IC20, pin 9 
and fly that signal out on your own 
lead. This requires you to remove 
the big PCB called Main Unit, turn 
it over and do some fine re-work 
among the sea of surface mounted 
devices. Alternatively, you can 
pick up a downstream version of 
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the signal without removing the 
PCB, at the optional tone-squelch 
unit-B socket J20, third pin from 
the “J”. Incidentally this signal is 
DC coupled to the discriminator 
chip, so you can implement 
closed-loop AFC externally using 
one of the many published circuits. 
The source impedance is 47K 
(R329), 


I checked Uosat-22 and 
KitSat-23 on Sub-band using this 
modification. The UO-22 “eye” is 
poor when it leaves the satellite, 
with a lot of LF flutter which has 
always made decoding difficult. 
But the 9600 bps performance of 
the Sub band receiver is so good it 
adds little extra aberration and data 
decoding was quite satisfactory. 
The KitSat-23 “eye” was wide 
open, and data detection perfect. 


Since there is no AFC indication 
for Sub band, tracking the 
changing doppler shift unaided 
requires either very good 
judgement, an external system as 
above, or computer control. 


Oh, and once again set the mic. 
gain to zero, or microphone sounds 
will be added to your transmission. 


9600 bps DFM Terrestrial 

Terrestrial 9600 bps packet 
works perfectly, “right out of the 
box.” 


Over the last six years I’ve tested 
innumerable radios for 9600 bps 
operation. The Icom IC-820H now 
shares top place with Kantronics’ 
D4-10. (The latter is however 
2-channel, crystal controlled and 
UHF only). 


9600 bps packet requires the 
TXAudio to be applied direct to the 
transmit FM varactor. RXAudio 
must be picked off directly from 
the FM discriminator, and the 
system is simplex. 


Thus the internal MOD slider 
switch needs to be set to PACT, 
which also selects RX Audio from 
FM Main’s discriminator. 
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The transmitter circuit’s 
frequency response is from about 
15 Hz to well beyond 6 kHz, so the 
outgoing signal has superb fidelity. 


If the drive signal exceeds 1.6 
volts pk-pk, corresponding to 
about +/- 5 kHz deviation, 
modulation is switched off 
abruptly and stays off until you 
reduce the drive. A nice touch. The 
correct drive level is 1 volt pk-pk 
for +/- 3 kHz deviation and I 
confirmed this by measurement. 


The FM Main and Sub receive 
circuits are similar. Main uses a 
pair of Icom part no. FL-211 
crystal roofing filters (no spec) and 
a muRata SFH455E ceramic final 
filter; Sub uses a pair of FL-212 
and the muRata CFW455E. The 
“EB” suffix means [5 kHz 
bandwidth. The SFH types have 
particularly flat delay 
characteristics, and are pin 
compatible with the more common 
general purpose CFW series. 


Main’s fidelity is outstanding, 
with a flat frequency and delay 
response to over 6 KHz. The “eye” 
was essentially perfect. You can be 
mistuned by up to +/- 4 kHz before 
the “eye” starts to look mangled, 
and +/- 5 kHz if the packets are 
short. The Sub receiver is almost 
equally good, but you can’t get at 
it without modifying the radio as 
described earlier. 


No quibble with Icom’s claims 
here; 9600 bps simplex works 
101%. 


PSK Satellite Doppler 
Tracking 

When using a 1200 bps PSK 
digital satellite such as FO-20, 
PacSat, Lusat or Weber it is 
essential that the PSK modem can 
control the radio receive frequency 
in aclosed loop fashion, preferably 
in small steps. The universal means 
of doing this is via the Up/Down 
buttons of the microphone socket. 
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The smallest step from the mic 
Up/Down buttons of the IC-820H 
is 100 Hz. This really is too big, as 
the sudden lurch from one 
frequency to the next will 
invariably cause momentary loss 
of demodulator lock, with 
attendant corrupted characters. 


The Up/Down line is also 
accessible from the accessory 
socket, but it shares a pin with the 
ALC control. You select which 
from an internal slide switch. 


There seemed to be no way of 
changing the mic. button step size 
to smaller than 100 Hz. An 
oversight? 


RS-232 Control 

Icom’s system is called CI-V 
(Communication Interface 5), and 
is accessed by a rear panel jack 
with a bi-directional service. The 
voltage is TTL-ish. You’re 
supposed to buy the CI-V interface 
which converts to RS$232 levels, 
and also, L assume, de-multiplexes 
the input and output. The manual 
only provides a limited description 
of the control codes required; I 
guess a full treatise comes with the 
interface. In particular I couldn’t 
determine what frequency 
resolution is available via RS-232 
control. 


Other Observations 

1. There is a miniature 40mm 
fan inside the PA section which 
comes on when the radio is too hot, 
and the TX is keyed. I spotted the 
fan on the schematic, but I couldn’t 
find it inside the radio until I 
provoked it into action during a 
megabyte file transfer at full power 
and a 75% duty cycle. The noise is 
less than a typical computer’s. 


2. If you want to use speech you 
must switch your TNC off or 
disconnect it from the accessory 
socket, otherwise your speech will 
be obliterated by data. This is not 
mentioned in the manual! 


3. There is no VOX system. 
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Witticisms 

The manual is beautifully laid 
out, with explanations crystal 
clear, quite devoid of Janglish. 
Fortunately, two useful tips 
escaped the proof-readers: 


IF Shift Control, page 24: 


“Especially in CW mode, a 
mechanical noise may sound when 
rotating the [SHIFT] control, 
however, it is not a transceiver 
malfunction.” I’m still decoding 
that one. 


Satellite Notes |., page 35: 


“NEVER set the output power 
too high. Too much power will 
shorten the satellite’s life.” Ah so. 


Conclusion 

The IC-820H wasn’t really 
designed with satellite operation as 
its primary application. It’s 
unlikely to win the hearts of serious 
satellite users, in the same way as 
Yaesu’s FT-736R, mainly because 
of its lack of flexibility. 


But an average user who wants 
to try out transponding satellites 
such as Oscar-13 will find it a 
satisfactory starting point. With the 
PacSats, 1200 bps doppler tracking 
is awkward, and 9600 bps full 
duplex operation requires you to 
modify the radio, 


The IC-820H is a nice radio if 
your needs are normal VHF/UHF 
operating, although serious 
VHF/UHF users will bemoan the 
lack of control over external 
equipment. It is also fine for low 
speed data transmission, and is 
among the first general purpose 
radios that provides 9600 bps 
packet radio simplex capability 
straight out of the box, at which it 
excels. 
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Outline of a Broadcast 
Protocol using Negative 
Acknowledgement 


Dirk-Jan Koopman 
djk @dirku.demon.co,uk 


A better generic name for this 
protocol might be ’group 
communication’ rather than a 
“broadcast protocol.’ It is designed 
to be used in a situation where a 
number of packets of information 
must be shared reliably between a 
relatively small group of stations 
which can normally hear one 
(central) station which we shall call 
the sequencer, 


Actually, ‘relatively small’ 
could be a quite large number (as 
hopefully will become apparent). 
*Smalil,’ in this case really means 
finite. 


The protocol described is 
précised from [Tanenbaum 1992 - 
Modern Operating Systems] and 
also [Kaashoek et al. - Group 
Communications in Amoeba and 
its Applications]. 1 say précised, 
because most of the detail has been 
left out — hopefully nof to the 
detriment of understanding! There 
is nothing the principles outlined 
which are Amoeba specific. In 
particular, whether you implement 
this on top of AX.25 or Amoeba 
FLIP or IP is largely irrelevant. 


There are some particulars left 
out in this document which include 
joining and leaving a group, plus 
some housekeeping details which 
are probably implementation- and 
underlying transport-dependent. 


Group communications is so 
called because you are 
communicating with a closed (or 
finite) group of other stations. 


The aim of this protocol is to 
allow reliable communications 
from one member of the group to 
the whole group with an average of 
just over two packets for the whole 
group (if incoming packets are on 
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the same frequency) or just over 
one packet, if incoming packets are 
on another frequency. Also, the 
order of the packets is guaranteed. 


Before you can start, as touched 
on earlier, a special station must be 
selected to act as a *sequencer;’ as an 
aside, in Amoeba, this is done by 
election as it is a multiprocessor 
based operating system and all 
kernels are created equal for this task; 
in Amateur radiouse, itis much more 
likely that we will have a suitably 
located station dedicated (at least 
partly) to this purpose. 


The sequence of events is roughly 
as follows: 


There are 4 stations in the group 
(A,B,C,D say) and the sequencer 
station (S). Station A wishes to send 
a message to all the other stations in 
the group. 


Therefore, station A sends a 
packet addressed to the sequencer S, 
with a unique message ID (used to 
detect duplicates), the sequence 
number of the last broadcast received 
by this station (used as a piggyback 
acknowledgement) and the message 
data itself. This station then starts a 
timer. 


If the broadcast comes back (from 
S) before the timer runs out, the 
sending station stops its timer and 
carries on (updating the sequence 
number of the last broadcast heard). 
If the broadcast is not heard and the 
timer has expired, then A assumes 
that either the message or the 
broadcast is lost. In either case the 
message is retransmitted. If the 
message was lost, then S broadcasts 
it in the normal way, otherwise S 
detects it as a duplicate and a simple 
acknowledgement is sent back to A 
instead. The message isn’t broadcast 
again. 


There is another possibility in 
that A might get another broadcast, 
from (say) B, in this case A knows 
that its message might well have 
got through, so it queues the 
message from B and still waits for 
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its broadcast to arrive from S or its 
timer to expire. 


At the sequencer, S, the 
following things happen when a 
point to point message arrives for 
broadcast: 


First a check is made to see if it 
is aretransmission, if it is, then the 
sender is sent a personal 
acknowledgement (as above). 


If the message ts a new one then 
the "next sequence number’ is 
applied to it and the "next sequence 
number’ is incremented, ready for 
the next message. The message and 
its indentifier is stored in a "history 
buffer’ and the message is then 
broadcast. If the sequencer 
happens to have an application 
process on it that is registered as 
part of the group then the message 
is then made available to it. 


Now let us look at what happens 
when one of the other stations (B,C 
or D) receives a broadcast: 


First the sequence number of the 
broadcast is compared to the last 
sequence number received (i.e. of 
the most recently received 
broadcast message). If the new one 
is exactly one higher, no 
broadcasts have been missed, The 
station then processes the packet. 


If the sequence number of the 
packet is more than one greater 
than the last one received, then one 
(or more) broadcasts has been 
missed. The broadcast that has 
been heard is queued, and a 
point-to-point request is sent to the 
sequencer S asking for a (private, 
in Amoeba) retransmission of the 
missing packet(s). When they 
arrive, all the packets are then 
passed up to the application in 
sequence number order as though 
nothing had happened. The only 
thing that has occurred is a time 
delay. 


An example 
If a newly received broadcast 
has sequence number 25 and the 
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last sequence number received was 
23, the protocol is immediately 
alerted to the fact that it has missed 
number 24. It sends a 
point-to-point message to the 
sequencer to this effect, the 
sequencer replies by resending 
message number 24 from its 
history buffer. When sequence 
number 24 is received, packets 24 
and 25 are passed up to the 
application (in that order) as if they 
had simply arrived together. 


The history buffer in the 
sequencer requires management. If 
nothing is done, then the history 
buffer will quickly fill up. There 
are several ways that the sequencer 
can determine that a certain 
number of messages have been 
received by each member of the 
group: 

1. Each request for a broadcast 
message contains a piggybacked 
acknowledgement which contains 
the sequence number, k, of the last 
successfully received broadcast. 
This means that all broadcasts up 
to and including, k, have been 
received, 


2. If a station has been silent for 
a certain (comparatively long) 
period of time it is required to send 
a short acknowledgement message 
informing the sequencer of its last 
heard broadcast sequence number. 


3. If the sequencer has not heard 
anything for a (even longer) period 
of time or its history buffer grows 
over some threshold size it can 
send a ‘request for status’ message, 
which directs all, or some, stations 
to send a message telling it the last 
broadcast sequence number 
received. 


In all cases, if there are missing 
broadcasts detected, by inference, 
then the missing packets are resent. 


In addition to the above, it is 
possible to produce any degree of 
fault tolerance into the system with 
a proportion of extra overhead. The 
degree of fault tolerance (i,e, the 
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number of sequencer stations that 
can go down before 
communications become 
unreliable) ts selectable — but the 
more ‘back-ups’ you have the 
more traffic is generated. The 
mechanism for this is outside the 
scope of this article — especially 
as | don’t think it is particularly 
relevant for our purposes at the 
moment. 


Summary 

This protocol allows reliable 
broadcasting to be done on an 
unreliable network in just over two 
packets per reliable broadcast (if 
all stations are on the same transmit 
and receive frequency, nearly one 
if the frequencies are different). 


All application programs 
receive all messages in the same 
order sent regardless of how many 
messages are lost. 


The worst that can happen is that 
a short delay is introduced when a 
packet is lost, which should happen 
infrequently if the sequencer site 
and tts frequency are carefully 
chosen. 


If two processes attempt to 
broadcast at more or less the same 
time, one of them will get to the 
sequencer first and win. The other 
will see a broadcast from the first 
station and wait, in case its 
message has been queued and thus 
will appear shortly. If it doesn’t, 
then it simply resends. 


This protocol could form the 
basis of a group communications 
protocol particularly where direct 
‘real-time’ one-to-many 
communications are needed; 
examples include DX clusters or 
chat servers. This could (probably) 
be done using AX.25 UI 
(Unumbered Information) frames. 


It is perfectly possible to 
implement this protocol (or at least 
the non-sequencer user part of the 
protocol) within a TNC or 
equivalent with minimal overhead. 
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TAPR Technical Support 
Group 


TAPR is looking for more 
people to participate in our 
Technical Support Group. This 
group handles the day to day 
questions the office receives about 
technical issues, It is important that 
we get some more people involved, 
so that we do not burn-out our 
current volunteers, 


Technical support for all TAPR 
kits and projects is supported by 
volunteers. The more volunteers 
we have helping, the better TAPR 
can help folks with their problems. 
Due to the amount of information 
requests and technical support 
TAPR receives, we have had to 
begin to prioritize members above 
non-member requests. This has left 
some requests from non-members 
for help and information delayed 
for weeks, instead of days as it 
might be if we had more help 
available. Many of the recent 
postings on packet and Internet 
about TAPR’s lack of technical 
help is a result of not having 
enough people within the 
organization volunteering with 
support and information issues. 
These non-members are future 
members if we can help them with 
their problems and concerns. 


We are looking for additional 
help in the following areas: 

+ TAPR 9600 baud modem kit 

« TNC problems and upgrades 

* DCD Kits 

* Operating Help 

* BBS Questions 

+ TCP/IP and NOS 

* Lots of General Packet Radio 

Questions 

If you think you might like to 
help work with folks on their 
problems, please send email to 
tapr@tapr.org or. contact Dorothy 
at the office to have your name 
placed on the list. Providing this 
help takes maybe 30 minutes to an 
hour a week depending on the area 
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and the amount of questions we are 
getting in. The more people we 
have involved in each area, the less 
time everyone in a specific group 
spends on correspondence. You 
can also be in more than one area 
if you want. If you have another 
area you fee] you would like to 
cover, please pass that along to us. 
We can then make a note of that 
and use you when and if we get a 
question in that area. 


We are also looking for a 
technical support group manager 
to help coordinate the follow-up on 
technical issues within TAPR. If 
you think you might be interested 
in this, please e-mail tapr@tapr-org 
or contact Dorothy. 


In addition, we are on the 
lookout for the names of any 
regional elmer groups that we can 
pass out. We have lists for some 
sections of a few states, but we are 
looking for more. Local elmers are 
sometimes the best solution to any 
question or problem. This also 
applies to any regional packet 
groups that might be doing the 
same thing. 


TAPR Technical Support 
Policy 


Greg Jones, WD5IVD 


We have had some complaints 
from individuals that do not 
understand how TAPR operates. I 
want to state for all the 
membership how technical support 
is done and I would hope that the 
membership can help those 
non-members better relate to how 
TAPR works. 


Most technical help and 
questions are received by mail and 
phone calls. When someone asks 
TAPR for technical help or to 
answer a question the office 
forwards the request to someone 
on the technical/question support 
list. The volunteer then answers the 
questions by phone (many times by 
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making acollect call) or by writing 
a letter in reply. Most amateurs 
asking for help are not on a 
commercial e-mail service or they 
would be asking there. 


I think it is important to publish 
our current Kit Return and 
Technical Support policy, so 
everyone can read it. One reason 
TAPR is able to keep it costs low 
is because it does not have to hire 
someone full time to handle 
technical support. In the past Lyle 
Johnson, WAT7GXD,_ did 
numerous hours a week on 
technical support, With Lyle 
moving on to more fun activities 
for his talent and interest, members 
within TAPR must take over that 
load. This process will take time 
and effort to attain the type of 
response Lyle was able to provide. 
How many companies in the world 
would have had someone of Lyle’s 
capabilities handling this type of 
task? 


This is the statement that is 
sent with all TAPR kits: 

Thanks for purchasing a TAPR 
kit. 


Before you get to building your 
kit, please take a moment and read 
the following about kit return and 
technical support. 


Kit Return / Refund Policy: 
TAPR kits can be complex 


depending on kitting experience of 
each builder. Before you unpack 
all your components, read through 
the documentation and determine 
if you believe you will have any 
problems assembling or making 
operational your TAPR kit. 
Consider carefully whether you 
wish to proceed with the 
unpacking of your kit. Once you 
begin construction, we cannot 
accept it back for refund. 


We don’t think you will have 
trouble with most of TAPR’s kits, 
but some require special 
knowledge or experience in order 
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to successfully go from a kit to a 
finished, usable unit. 


If you decide to return your kit 
for a refund, contact the TAPR 
office (below) via mail, phone, or 
fax for a Return Authorization 
Number. Mark the outside of the 
package clearly with the R.A. 
number and ship it to the shipping 
address given to you at the time of 
the R.A. number. Upon inspection 
of the returned kit, you will receive 
your purchase price, less shipping 
and handling. If you return the 
package without an R.A. number, 
it will be returned, 


If you have any questions, you 
can call the TAPR office at the 
number listed. 


Technical Support 

Technical support for TAPR kits 
is handled on a volunteer basis. 
Each kit has a technical support 
specialist and all questions are sent 
to this person. Replies are then 
mailed or faxed back when the 
volunteer has a chance to cover 
your question. This might take a 
week to several weeks, depending 
on the topic and time of support. A 
Technical Support Form has been 
included with your kit. Some kits 
contain a Frequently Asked 
Questions list, which provides help 
on the more common problems. 


If you have a Technical Support 
request, please complete the form 
and either fax or mail it to TAPR at 
the below address. You might try 
calling the office for some 
problems, but the office manager is 
not a technically sophisticated 
hobbyist, so she can only write 
down your problem, which is 
much better represented by using 
the Technical Request Form. The 
form allows for fewer problems in 
translation over the phone of 
problems. 


Summer 1994 - Issue #55 


Update on the RUDAK-U 
Project 


Lyle Johnson, WA7GXD 


The design team for RUDAK-U 
(myself, Chuck Green, Harold 
Price, Peter Guelzow, and Jeff 
Ward) have been having 
discussions and doing some testing 
since the last PSR. We have all 
been busy with other aspects of the 
P3D spacecraft, as well as others, 
so the progress is a little slower 
than we would like. The good news 
is that you can still give us your 
comments — it isn’t too late! 


The primary flight computer for 
P3D is called the Integrated 
Housekeeping Unit (IHU). This 
IHU is substantially the same as the 
one flying on AO-13, The primary 
differences are: (a) increased 
memory from 32k bytes to 64k 
bytes; (b) inclusion of the 
command decoder on the IHU PC 
board; (c) the [HU is now a single 
PC board; (d) the IHU is now ona 
multi-layer PC board. Why do T 
mention the [HU? Without it, 
there is no P3D — hence, no 
RUDAK U! So, [have been giving 
priority to the IHU design over that 
of RUDAK U. 


Also, the GPS experiment team 
has been doing some radiation 
testing. Paul Barrow has 
assembled a team of folks in 
Canada and they have already 
determined a suitable switching 
power supply chip for use in a 
number of modules on P3D — 
including, of course, the GPS, 
RUDAK and IHU modules. Peter 
Guelzow has done some testing of 
an Analog Devices 7008 Direct 
Digital Synthesier chip and it looks 
absolutely outstanding. It will very 
likely be the heart of the 
experiemental modulators on 
RUDAK E and be used on the DSP 
channels of RUDAK U. 


So, how does RUDAK U look at 
the moment? The CPU will 
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probably be an NEC V53 with a 
possible Intel i386EX as a backup. 
The CPU will have 16 megabytes 
of EDAC memory for program and 
message storage. The maximum 
number of uplink and downlink 
channels hasn’t yet been fixed, but 
there may be as many as 12 uplinks 
and 4 downlinks. There will be 
“fixed” channels and DSP 
channels. The fixed channels will 
probably be 9600 bps FSK. 


The system will be able to adjust 
the relative powers of its 
downlinks. This means that at 
times there may only be a single, 
very strong downlink. At other 
times there may be more 
downlinks running, but with 
weaker signals. My preliminary 
link calculations show that you 
will need reasonable antennas on 
your packet station to make full use 
of RUDAK-U, The downlink from 
the satellite will be marginal if we 
run four of them with equal power 
and you are at the edge of the 
antenna pattern from the satellite. 
You will need antennas with about 
10 dB gain on 2 meters, 13 dB gain 
on 70 cm or 22 dB at S-band. None 
of these gains are hard to come by, 
but you won't be able to use a 3 
element beam or aJ-pole! If we run 
a single downlink, and we generate 
18-20 watts of RF on it at the 
spacecraft, you should have an 
extremely loud signal with these 
types of antennas and a useable 
signal with maybe 4 to 6 dB less 
gain. These calculations were 
based on published numbers for 
the spacecraft antenna system 
gains and very conservative 
numbers for the transmitter power 
levels. Of course, we could gain 
nearly 12 dB in performance 
margin if we had 1200 bps PSK 
downlinks, but I suspect most of 
you would rather we didn’t make 
another 1200 bps satellite... 
(Comments, please!) 


A possible scenario is to have a 
downlink using most of the power 
most of the time with 2 or 3 other 
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downlinks using less power. Then, 
if you don’t have a great antenna 
system, you can still use 
RUDAK-U. If you have a better 
system, you can switch over to 
less-congested channels. The DSP 
channels will be fewer in number, 
perhaps 4 uplinks and 2 downlinks. 
The purpose of these is to have 
flexibility in modulation 
techniques as we progress in 
packet technology over the next 
ten or twelve years. I expect to 
report on both the final system 
design and on prototype status in 
the next issue, Thank you for your 
support of P3D and of RUDAK-U! 


Network Enhancements 
Implemented in the 
CT/NJ/NY Region 


Frank Warren, Jr., KB4CYC 
Andrew Funk, KB7UV 

Scott Weiss, KBZEAR 

Ad-Hoc Tri-State Managed Packet 
Group (MGTBBS) 


[From the TAPR BBS-SIG mail 
group.] 


Summary 

The problems of the 
proliferation of flood routings, 
widespread mesh forwarding, and 
an ever-expanding system census 
had combined to reach a point 
where the PBBS network in the 
CT/NJ/NY tri-state region was in 
dire need of an overhaul. This 
paper details the approaches taken 
by the majority of systems in the 
region to address these problems. 


Introduction 

As part of the June 1992 ARRL 
Hudson Division Convention, a 
forum was held for regional packet 
radio System Operators (sysops) 
and Network Administrators. Our 
aim was to begin dialog among 
those operating packet systems in 
the region, with the goal of 
improving the packet environment 
in the region for all concerned. 
(The systems “talked” with each 
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other, but not the people behind the 
systems,., Until this meeting.) 


Since this June meeting, Sysops 
and Network Managers in the 
tri-state region have continued 
meeting and planning. This work 
has developed a cooperative 
system for the distribution of 
bulletins. The solution developed 
combines a consensus on which 
distribution routes will be 
supported, alist of suggested “To:” 
fields which users are encourged to 
use, cellular hub and spokes 
bulletin distribution topology, and 
time reserved exclusively for user 
access to PBBSs and other network 
services. 


Forwarding 'Quiet Hours’ 

The initial decision reached by 
the group was to prohibit 
BBS-to-BBS forwarding between 
1800 and 2400 local time on all 
paths which may also carry 
real-time user data. This provides 
users with six hours each day, 
during prime time, when their 
enjoyment of the packet network is 
not impaired by contending with 
automated stations. 


Hub and Spokes 
Forwarding Topology 

At the group’s mid-July 
meeting, a plan to reduce 
bandwidth consumption by 
bulletin distribution was 
formulated. Bulletin distribution 
now follows a cellularized, 
hub/spoke or server/client design. 


Many of the systems in the 
region use a series of regional 
backbone nodes maintained as part 
of the Eastnet Backbone Network 
(EBN). Others are served by the 
ROSE X.25 Packet Network 
maintained by the Radio Amateur 
Telecommunications Society 
(RATS). 


Those systems using the EBN 
regional nodes receive their 
bulletins from a single, designated 
hub/server within their cell. The 
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cells were defined based upon the 
existing backbone EBN nodes. 
The cells currently resolve to 
Connecticut, Long Island, New 
York City, Downstate New York, 
Northern New Jersey and Central 
New Jersey. Cell size and 
definitions may change, over time, 
as a function of network traffic and 


topology. 


The RATS ROSE Network has 
bi-directional connectivity with 
the two New Jersey EBN-based 
cells and a bi-directional feed to the 
cellularized (non-EBN) network in 
Southern New Jersey. Bulletin 
distribution for systems on this 
network also follows the 
client/server model. 


This design has freed the 
bandwidth previously occupied 
(wasted!) by everyone trying to 
forward everything to everyone 
else. In addition, this dual-network 
topology provides redundancy and 
robustness often lacking in 
Amateur packet networks. 


Supported Flood 
Distributions 

Table | is the list of flood 
distributions (@-field routes) the 
region has decided to support for 
forwarding. 


Suggested “To:” Fields 

Table 2 is a list of “To:” fields 
the group decided to distribute as a 
partial list of suggestions. The 
entries for the various PBBS 
software were originaly proposed 
as flood routes, but were recast as 
“To:” values based on explicit 
statements and examples from 
several PBBS software authors. 


Conclusion 

The plan outlined above, 
combined with ongoing efforts in 
user education by the participating 
SYSOPs, has improved packet 
operation throughout this region. 
While not all of these steps may be 
as useful in other areas of the 
country, they may serve as a basis 
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Route 
xxBBS 
xxNET 
AMSAT 
ARESCT 
ARL 
ATLDIV 
CTBBS 
CTNET 
ENYBBS 
EPABBS 
HUDSON 
LOCAL 
NASA 
NEBBS 
NEWHDR 
NJEOC 
NJNET 
NJPSG 
NLIBBS 
NNJBBS 
NYNET 
PANET 
SNJBBS 
TRIBBS 
USBBS 
WNYBBS 
Www 


(Note: NJEOC and NUPSC were requested by NJ Office of Emergency Management.] 


To: 
ALL 
AMSAT 
BEACON 
CBBS 
CLASS 
DX 
EVENT 
EXAM 
FBB 
HELP 
ICOM 
KEPS 
KENWD 
MBLBBS 
MSYS 
PRMBS 
PROP 
QSL 
REBBS 
RLIBBS 
SALE 
SWAP 
SWL 
SYSOP 
USERS 
WANT 
YAESU 
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Table 1 - Bulletin Flood Routes 


Description and Usage 

Distribution to areas other than a state (ARRL sections, etc.) 
State-wide routing, using 2-letter state designation xx 

Amateur satellite (AMSAT) bulletins 

Conecticut Amateur Radio Emergency Service bulletins 

ARAL bulletins (@ARRL is not to be distributed) 

ARRL Atlantic Division distribution 

Connecticut ARRL Section distribution (same as CTNET) 

State of Connecticut distribution (same as CT ARRL Section, CTBBS) 
ARRL ENY Section distribution 

ARRL EPA Section distribution 

ARRL Hudson Division distribution 

Non-flood bulletin, for ONE LOCAL PBBS ONLY 

Material for NASA sources 

New England regional distribution (CT, MA, ME, NH, RI and VT) 
New Headers parsed by the N2MH program 

NJ State Office of Emergency Management Official bulletins 

NJ state distribution 

NJ Public Service Communications (includes ARES) 

ARRL NLI Section distribution 

ARRL NNJ Section distribution 

State of New York distribution 

State of Pennsylvania distribution 

ARRL SNuJ Section distribution 

Tri-State (CT, NY and Nu) regional distribution 

United States distribution (replaces ALLUS, ALLUSA, USABBS, USA) 
ARRL WNY Section distribution 

World-Wide distribution (replaces ALLBBS, WWW) 


Table 2 - Suggested “To:” Field Usage 


Usage 

Should only be used if nothing else applies! 
AMSAT-specitic space/satellite information 
Beacon lists and information 

Program-related distribution: CBBS 

Amateur Radio and other class announcements 
DX related information and questions 

Special events, on-air or not, including hamfests 
VE Exam session announcements 
Program-related distribution: FBB 

Requests for help which don't fit into other categories 
Icom product-specific postings 

Keplerian elements (satellite tracking) 
Kenwwod product-specific postings 
Program-telated distribution; MBL 
Program-related distribution: MSYS 
Program-related distribution: ROSErver/PRMBS 
Propagation reports 

QSL information: routes, managers, etc. 
Program-related distribution: AA4RE 
Program-related distribution: ALI 

Items for sale (Amateur Radio, of course!) 
Items offered for swap 

Short Wave Listening 

For System Operators (usually type “P”) 
Postings for System or Network Users 

ltems wanted 

Yaesu product-specific postings 
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for development of a broad-based 
(dare we hope world-wide?) 
consensus. We also urge the 
adoption of dedicated user time, 
for without users our systems are 
not needed. 


Contacting The Authors 

The authors of this paper, along 
with the sysops of all systems 
participating in the Ad Hoc 
Tri-State Managed Packet Group, 
can be contacted by sending (using 
the “SP” command) a single packet 


message addressed to: 
RMAIL@KB4CYC.NJ.USA 


and containing as the first line of 
text the following: 
To: rmail@kb4cyc.nj.usa, 
sysop@tribbs 

This Remote MAIL message 
will be processed automatically at 
the KB4CYC PBBS and become a 
flood bulletin to all the 
participating MGTBBS systems. 


Alternatively, as each of the 
authors operates a PBBS, they may 
be reached via packet radio using 
the following addresses: 
kbha4cyc@kb4cyc.nj.usa 
kb7uv@kb7uv.#nli.ny.usa 
kb2ear@kb2ear.nj.usa 


TAPR Mail Delayed 


Mail sent to TAPR at the old 
Tucson P.O. Box address during 
April, May, and June, was not 
forwarded to TAPR until July. If 
you sent mail to TAPR at the old 
address during this time period, we 
apologize for the delay. For all 
future mail to TAPR, please use the 
new address: 8987-309 E. Tanque 
Verde Rd. #337, Tucson, AZ. 
85749-9399. 


Renew Your Membership! 

TAPR sends out renewal 
reminders quarterly, but to find 
out when your membership will 


expire, check your mailing 
label. Your membership is very 
important. 
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TAPR 1995 Annual 


Meeting 
Mel Whitten, KOPFX 


TAPR will host its 1995 Annual 
Meeting in St. Louis, Missouri on 
March 3rd - 5th at the St, Louis 
Community College. The annual 
meeting will be co-hosted by 
MoAmPS (Missouri Amateur 
Packet Society). This should prove 
to be a really good meeting, since 
past Spring Packet Seminars 
hosted by MoAmPS have drawn 
upwards of 250+ people. 


The college location is 5 
minutes from the hotel and 10 
minutes from the Lambert St. 
Louis International Airport. TWA 
maintains a hub at this airport and 
Southwest, American, Delta, 
Continental, and others offer 
flights, We are stil] working on the 
contract with the hotel, so we will 
wait till that is signed before 
announcing the hotel location. The 
hotel we are working with offers 
rooms for $49 a night. One benefit 
is the availability of the meeting 
space, but transportation between 
the hotel and college is an 
outstanding issue for those that 
might not have local 
transportation. 


A very rough schedule contains: 
Friday: TAPR BOD Meeting, 
Hospitality Suite in Hotel, 
Informal Dinner, SIG meeting 
after Dinner; Saturday: 
Presentations (possibly with two 
streams), Lunch (TBD), 
Presentations, Dinner (TBD), SIG 
meeting; Sunday: Half-Day 
Workshop (one maybe two). As 
the meeting firms up, we will be 
publishing more information as to 
cost and various issues. 


We wanted to give everyone the 
date and location as soon as 
possible, so that you can mark your 
calendars early. This next year’s 
event is shaping up to be an 
outstanding one. 
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Items with ** notation have been updated since the last listing in PSR. 


TAPR Software Library 
Current as of | August 1994. 


Disk No. Name Version 
HA APLINK Ver. 7.01 
2/2A AA4RE BBS Ver, 2.12 
2 CBBS Ver. 7.20 
4. EZPAC Ver. 1.1 
5. MONAX 
6. Ham Comm Ver. 3.08 
if TNC-2 Manual and EPROMs 
8. Text conversion Ulilities 
R95 Ver, 4.0 
7PLUS Ver, 2.02 
UUENCODE/UUDECODE Ver. 5.21 
9, ROSERVER PRMBS Ver, 1,73 
10. ROSE X,25 SWITCH Ver, 3.1 
11: KASQ NET Ver. K34 
12. WXN Weaiher Svr. Ver. 5.14 
13. TNC1 CODE & TNC2 Notes 
14, Deleted; now included on disk 13, 
15. WA7MBL BBS Ver. 5.14 
16. WORLI BBS Ver. 16.12 
17, YAPP Ver. 2,0 
18/18A INTRO TO TCP/IP 
19/194 LAN-LINK Ver, 2.01 
20. ARESDATA Ver. 1.6 
21/21A MSYS Ver. 1.15 
22. G8BPQ NODE Ver. 4.07K 
23. UTILITIES 
PKARC Ver. 3.6 
PKZIP Ver. 2.04G 
LHA Ver. 2,11 
ZOO Ver. 2.10 
UUENCODE/UUDECODE _ Ver. 5.21 
24, THS Ver. 2.50 
25. VE4UB NTS Ver. 091891 
26. NM1D DOSGATE Ver, 1,14 
27. SV7AIZ BBS Ver, 3.24 
28. TEXNET Ver, 1.6 
29. Intro To Packet Radio, A Tutorial 
30. MICROSAT Ground-station Software 
PB 
PG 
PFHADD 
PHS 
31. No Longer Available (see 38/384) 
32. PAMS-Personal AMTOR Mailbox Ver. 2.08 
33. TNC-2 Z-80 Monitor Ver. 2.00 
34. GIL (Graphics Interchange Lang.) Ver. 1.03 
35, PAKET Ver. 5.1 
36/36A. F6FBB BBS Ver. 5.15 
37. TPK Ver. 164A 
38/38A. KA9Q JNOS (Executables, docs.) Ver. 1.10C 
39/39A. JNOS (Source Code for 38) Ver. 1.10C 
40, SP Packet Ver. 6,01E 
41. TAPR Deviation Meter Source and Tools 
42. PCTOR/PC-PACTOR Ver. 3.02A 
43. METCON ROM Code Ver. 1.07 


Orders for any of the above disks should be sent to the TAPR office. 
New submissions or updates should be sent to the TAPR Software 


Librarian: Lou Nigro, KW7H 
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Date 

02-28-93 
03-31-92 
01-05-93 
01-09-89 
10-30-87 
03-08-91 
09-29-92 


01-25-92 
06-25-92"* 
01-26-93 
05-08-92 
07-29-92 
01-14-94 
06-13-94 
03-28-90 


02-11-90 
01-25-94 
12-18-86 
09-09-87 
07-06-92 
12-31-92 
06-30-93 
01-01-94 


11-11-89 
09-18-91 
11-29-89 
04-05-90 
02-05-91 
05-07-93 


10-09-92 
02-25-92 
10-09-92 
12-21-90 


11-26-92 
09-02-91 
03-30-91 
04-06-92 
03-06-93 
04-14-91 
04-19-94** 
04-19-94" 
02-06-92 
10-01-93 
08-10-93 
01-17-93" 
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Tucson Amateur Packet Radio 
8987-309 ©. Tanque Verde Rd #3357 
Tucson. Arizona = 85749-9399 
Office: (817) 383-0000 = Fax: (817) 566-2544 Fall 1994 
Non-Profit Research and Development Corporation a 

All prices subject to change without notice and are payable in U.S. funds. Members receive 10% off on Kits and Publications. 


Please allow six to eight weeks for your order to be shipped. For specific information on kits, see Product Description flyer. 


Kits / Firmware / Publications Office Hours: Tue-Fri 9am-12pm, 3pm-Spm CST 


Qty Item Unit Price Total Price Kit Code Information 
TAPR 9600 bps Modem ..........0c0006 $ 80.00 6 
Bit Regenerator ..........cceceeeeesres $ 10.00 0 —_used for regenerative repeater operation 
HOCK CODTONL cs cstapschsnsosianccannenssges $ 5.00 0 __used for regenerative repeater operation 
Deviation Meter ............-:e:ecceeespenseree $ 95.00 5 limited kits available 
TRC BOR set si cnt seel Sonesta at Actahoatanatinial $ 195.00 6 _ limited kits available, member discount $10 
METCON-1 Telemetry/Control......... $ 85.00 1 includes 8 input, 4 output ports 
4 additional output ports............. $ 15.00 1 
Voltage-to-Frequency module.....$ 30.00 3 
Temperature-to-Freq module ......6 40.00 3 
A-D Converter ........ccceeecseeeee $ 45.00 3 
Elapsed Time Pulser ........c00s000 $ 35.00 3 
PK-232 Modem Disconnect ............. $ 20.00 2 simplifies connection of external modems 
PK232MBxX Installation Kit...........00. $ 20.00 2 __ for installation of 9600 modem in PK-232MBX 
XR2211 DCD Mod. ...0........cecseeseeee $ 20.00 1 
State Machine DCD Mod. .............0. $ 20.00 2 
State Machine DCD w/Int Clock........ $ 25.00 2 For KPC2 or other TNC w/o 16X or 32X int cloc 
TNC-2 bare PC Board .......cccccseceeee $ 40.00 4 Noparts. Incls schematic, manuals, EPROM cod 
32K RAM w/ TNC2 update docs ....... $ 20.00 1 
TNC-2 1,1,8a w/KISS EPROM ........ $ 15.00 2 includes 1.1.8 Commands booklet 
TNC-2 WA8DED EPROM ............... $ 12.00 1 8 connect version for ARES/Data standard 
TNC-1 WA8DED EPROM .........0000 $ 12.00 1 
PK-87 WA8DED EPROM ................. $ 12.00 1 
TNC-1 KISS EPROM .............:::-2000 $ 12.00 1 
TNC-2 KISS EPROM ...0.....cc0:ccceeees 12.00 1 
1.1.8 Commands Booklet ................ $ 8.00 1 full TNC-2 command set for 1.1.8 
TAPR's Packet Radio General Info...$ 7.00 1 40 page book for the beginner to intermediate 
TAPR's 94 Annual Proceedings........ $ 7.00 1 53 pages. Papers from the Annual Meeting 
PSR Set Vol 1 (#1 - #17 '82 -'85) .....$ 20.00 5 
PSR Set Vol 2 (#18 - #36 '86 -'89) ...6 20.00 7 
PSR Set Vol 3 (#37 - #52 '90 -'93) ...$ 20.00 7 
NOSIntro, Intro to KASQ NOS ......... $ 23.00 5 lan Wade, G3NRW, TCP/IP over Packet Radio 
ARRL CNC Proceedings 1st - 11th... call ‘ Inidividual Proceedings, call for prices 
Entire Set ARRL CNC ist- 11th .......6 80.00 7 8 Proceedings from 1981 to 1992 
TAPP Bade waiccnctsceasssscusvrcssreent verves $ 10.00 0 _ include Name and Call for badge 
Sub-Total Kits/Firmware/Publications: .WHbss_____ :Added Total of Kit Codes 
(Example: 3600modem w/ BitRegen: 6 + 0 = 6) 
Members 10% Discount (Kits & Publications): — :Member # (Place New, if joining) 
+ Sub-Total Disk Purchase (see reserve) 
Sub-Total (Kits - Discount + Disks) 
Texas Residents add 7.25% tax 
Membership (each year) ..........s.ccccssesesssseeseseseecneseetes Membership (New or Renwal) 
$15 per year US and possessions, For Total Kit Codes between: 
$18 Canada/Mexico, $25 elsewhere — 
(Join and place NEW in above Member # 1-3 | 4-7 | 8-15 |16-27 | 28-55 
to receive your 10% member discount!) Add $2 |Ada $3] Add$4 | Adass | Aaa $6 
TOTAL Order Amount Kit Codes above 55 or INTERNATIONAL orders 
~ Please call TAPR for Shipping & Handling Amount 
Credit Card # Expires: Signature: 
(Visa/Mastercard Only) 
Name: Callsign: City, State: 


Address: Zip, Country: 


The Tucson Amateur Packet Radio Corporation is a non-profit, scientific 


research and development corporation. TAPR is chartered in the State of TAPR Board of Directors 
Arizona for the purpose of designing and developing new systems for packet Board Member Term Internet 
radio communication in the Amateur Radio Service, and for freely dissem- Ron Bates, AG7H 1995  ag7h@tapr.org 
nating information required during, and obtained from, such research, Jack Davis, WA4EJR 1995 wadejr@tapr.org 
The officers of the Tucson Amateur Packet Radio Corp. are: Bob Hansen, N2GDE 1996 n2gde@tapr.org 
Greg Jones, WDSIVD President Gary Hauge, NACHV * 1996  ndchy@tapr.org 
Keith Justice, KF7TP Vice President Greg Jones, WDSIVD * 1997 wdSivd@tapr.org 
Cary Hauge, NSCHV Becretary Keith Justice, KF7TP * 1996 ~—_— kf 7tp @tapr.org 
Jim Neely, WASLHS Treasurer John Koster, W9DDD 1997 w9ddd @tapr.org 
The Packet Status Register is the official publication of the Tucson Jim Neely, WASLHS * 1995  waSlhs@tapr.org 


Amateur Packet Radio Corporation. Unless otherwise indicated, explicit 


permission is granted to reproduce any material appearing herein, provided Mel Whitten, KOPFX 1997 kOpfx @tapr.org 
credit is given to both the author and TAPR. , ga ed , 
TAPR Membership and Date is expiration of term on Board of Directors. 


PSR Subscription Mailing Address: 
Tucson Amateur Packet Radio Corp. 


Asterisk indicates member of Executive Committee, 


8987-309 E. Tanque Verde Rd, #337 The Board encourages input from all interested members. 
Tucson, AZ 85749-9399 If you have an issue you want addressed, or an idea for a project 
Phone: 817-383-0000 you would like TAPR to sponsor, contact any Board member, 
FAX: 817-566-2544 or drop a note to the TAPR office. 
Office Hours: TAPR is now accessable through the Internet. You may 
Tuesday - Friday send e-mail messages (no long files, please) to the TAPR 
9:00-11:00am, 3:00-5:00pm C.S.T. office at 
14:00-16:00, 20:00-22:00 UTC i ala cia 
and to any of the directors at 
PSR Editorial Address: TAPR Software . callsign@tapr.org 
Bob Hansen, N2GDE Librarian: 
PSR Editor Lou Nigro, KW7H substituting their call for “callsign.” Also, submittals for 
P.O. Box 1902 11245 East Limberlost Road Packet Status Register may be sent to 
Elmira, N.Y. 14902-1902 Tucson, AZ. 85749-9518 psr@tapr.org 
CompuServe: 71121,1007 Internet: kw7h @tapr.org 


Internet: psr@tapr.org 
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ADDRESS CORRECTION REQUESTED 


Check your address label for membership expiration date. Your renewal is important! 


DENTON, TX. 


